[openstack-dev] [OPENSTACK] [HORIZON] Changing theme

[BIKRAMADITYA SAHOO]

Hi,

I am unable to change the theme for my openstack horizon. I tried with the
this  and
various other tutorial but i am still unable to achieve my goal.

I also want to have a custom "splash" (a complete custom login) and i am
unable to find any good tutorial.

I tried "local_settings.py" with following
CUSTOM_THEME_PATH="static/themes/production"
CUSTOM_THEME_PATH="themes/production"
CUSTOM_THEME_PATH="static/production"

"production" directory is present in
"/usr/share/openstack-dashboard/openstack_dashboard/static/themes" as well
as "/usr/share/openstack-dashboard/openstack_dashboard/static/custom"
directories.

Also i tried deleting the "i/usr/share/openstack-dashboard-ubuntu-theme"
and
"/usr/share/openstack-dashboard/openstack_dashboard/local/ubuntu_theme.py"
and still no use.

No matter what i do, horizon is loading images from "static/themes/ubuntu "
directory ("
http://controller/static/themes/ubuntu/image-background-pattern.png";).

Kindly point me to anything i am doing wrong or/and any well-documented
tutorial or docs.

NOTE: I want to have the above changes in an already running setup by
manipulating files.

Thanks and Regards,
Bikramaditya Sahoo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][scheduler] A simple solution for better scheduler performance

[Cheng, Yingxin]

It is easy to understand that scheduling in nova-scheduler service consists of 
2 major phases:
A. Cache refresh, in code [1].
B. Filtering and weighing, in code [2].

Couple of previous experiments [3] [4] shows that “cache-refresh” is the major 
bottleneck of nova scheduler. For example, the 15th page of presentation [3] 
says the time cost of “cache-refresh” takes 98.5% of time of the entire 
`_schedule` function [6], when there are 200-1000 nodes and 50+ concurrent 
requests. The latest experiments [5] in China Mobile’s 1000-node environment 
also prove the same conclusion, and it’s even 99.7% when there’re 40+ 
concurrent requests.

Here’re some existing solutions for the “cache-refresh” bottleneck:
I. Caching scheduler.
II. Scheduler filters in DB [7].
III. Eventually consistent scheduler host state [8].

I can discuss their merits and drawbacks in a separate thread, but here I want 
to show a simplest solution based on my findings during the experiments [5]. I 
wrapped the expensive function [1] and tried to see the behavior of 
cache-refresh under pressure. It is very interesting to see a single 
cache-refresh only costs about 0.3 seconds. And when there’re concurrent 
cache-refresh operations, this cost can be suddenly increased to 8 seconds. 
I’ve seen it even reached 60 seconds for one cache-refresh under higher 
pressure. See the below section for details.

It raises a question in the current implementation: Do we really need a 
cache-refresh operation [1] for *every* requests? If those concurrent 
operations are replaced by one database query, the scheduler is still happy 
with the latest resource view from database. Scheduler is even happier because 
those expensive cache-refresh operations are minimized and much faster (0.3 
seconds). I believe it is the simplest optimization to scheduler performance, 
which doesn’t make any changes in filter scheduler. Minor improvements inside 
host manager is enough.

[1] 
https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L104
 
[2] 
https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L112-L123
[3] 
https://www.openstack.org/assets/presentation-media/7129-Dive-into-nova-scheduler-performance-summit.pdf
 
[4] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098202.html 
[5] Please refer to Barcelona summit session ID 15334 later: “A tool to test 
and tune your OpenStack Cloud? Sharing our 1000 node China Mobile experience.”
[6] 
https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L53
[7] https://review.openstack.org/#/c/300178/
[8] https://review.openstack.org/#/c/306844/


** Here is the discovery from latest experiments [5] **
https://docs.google.com/document/d/1N_ZENg-jmFabyE0kLMBgIjBGXfL517QftX3DW7RVCzU/edit?usp=sharing
 

The figure 1 illustrates the concurrent cache-refresh operations in a nova 
scheduler service. There’re at most 23 requests waiting for the cache-refresh 
operations at time 43s.

The figure 2 illustrates the time cost of every requests in the same 
experiment. It shows that the cost is increased with the growth of concurrency. 
It proves the vicious circle that a request will wait longer for the database 
when there’re more waiting requests.

The figure 3/4 illustrate a worse case when the cache-refresh operation costs 
reach 60 seconds because of excessive cache-refresh operations.


-- 
Regards
Yingxin

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

Re: [openstack-dev] [TripleO][os-net-config] add support for NFV virtual switch

[Steven Hardy]

On Tue, Jul 12, 2016 at 04:38:49PM -0500, Ben Nemec wrote:
> On 07/07/2016 05:45 PM, Xin Wu wrote:
> > Hi,
> > 
> > This is Xin from Big Switch. I'm proposing to make os_net_config support
> > DPDK switch for NFV workloads.
> >  Current os_net_config supports ovs_bridge, linux_bridge, ivs_bridge
> > and different types of interfaces. The os_net_config's abstraction is
> > perfect to support DPDK switches for NFV workloads as well.
> >  If this proposal makes sense, I would love to start with adding the
> > support for Big Switch's DPDK switch first, which is called nfv-switch.
> > The code change will be very similar
> > to https://review.openstack.org/#/c/274492/
> 
> This sounds reasonable to me, so I would say go ahead and propose the
> patch so we can discuss implementation on Gerrit.

+1, sounds good, please go ahead and we can discuss on the gerrit review

Steve

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

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Steven Hardy]

On Tue, Jul 12, 2016 at 03:39:41PM -0400, John Trowbridge wrote:
> Howdy folks,
> 
> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> is being used as a CI tool in RDO. This came about organically, because
> we needed to use RDO CI to self-gate quickstart (it relies on having a
> baremetal virthost). It displaced another ansible based CI tool there
> (khaleesi) and most(all?) of the extra functionality from that tool
> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> roles that are able to plugin to quickstart.[1]
> 
> We are still left with two different tool sets, where one should suffice
> (and focus CI efforts in one place).
> 
> I see two different ways to resolve this.
> 
> 1. Actively work on making the tripleo-ci scripts consumable external to
> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> upstream CI for packstack and puppet, so it is not totally far-fetched
> to add support for TripleO jobs.
> 
> Pros:
> - All CI development just happens directly in tripleo-ci and RDO just
> inherits that work.
> 
> Cons:
> - This is totally untried, and therefore a totally unknown amount of work.
> - It is all or nothing in that there is no incremental path to get the
> CI scripts working outside of CI.
> - We have to rewrite a bunch of working ansible code in bash which IMO
> is the wrong direction for a modern CI system.
> 
> 
> 2. Actively work on making tripleo-ci consume the ansible work in
> tripleo-quickstart and the external role ecosystem around it.
> 
> Pros:
> - This could be done incrementally, replacing a single function from
> tripleo.sh with an invocation of tripleo-quickstart that performs that
> function instead.
> - We would be able to pull in a lot of extra functionality via these
> external roles for free(ish).
> 
> Cons:
> - Similarly unknown amount of work to completely switch.
> - CI development would be done in multiple repos, though each would have
> discrete and well defined functionality.

I think I prefer the incremental conversion to use tripleo-quickstart - if
we're aiming to have that be the one recommended way to bootstrap a tripleo
environment, it should be what we test in CI IMO.

Personally I've avoided switching to tripleo-quickstart locally primarily
because it's not what we test in CI, so it's sometimes harder to reproduce
CI impacting problems (and there were a few dev workflow nits, which may
well have been fixed now) - so anything which can align what *all*
developers and upstream users test with what we CI gets a big +1 from me.

> Personally, I don't think we should do anything drastic with CI until
> after we release Newton, so we don't add any risk of impacting new
> features that haven't landed yet. I do think it would be a good goal for
> Ocata to have a CI system in TripleO that is consumable outside of
> TripleO. In any case, this email is simply to garner feedback if other's
> think this is a worthy thing to pursue and opinions on how we can get there.

Yeah I think this is sensible - unless there are some very low-risk
increments that we can take we should wait until newton ships, but there's
nothing to stop folks working on a series of WIP tripleo-ci patches in the
meantime (that repo is low-traffic enough that the rebase pain probably
won't be too bad?)

Thanks for starting this discussion!

Steve

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

Re: [openstack-dev] [Openstack] Naming polls - and some issues

[Monty Taylor]

(top posting on purpose)

I have re-started the Q poll and am slowly adding all of you fine folks
to it. Let's keep our fingers crossed that it works this time.

I also removed Quay. Somehow my brain didn't process the "it would be
like naming the S release "Street"" when reading the original names.
Based on the naming critera, "Circular Quay" would be a great option for
"Circular" - but sadly we already named the C release Cactus. It's
possible this choice will make someone unhappy, and if it does, I'm
certainly sorry. On the other hand, there are _so_ many awesome names
possible in this list, I don't think we'll miss it.

I'll fire out new emails for P once Q is up and going.

On 07/15/2016 11:02 AM, Jamie Lennox wrote:
> Partially because its name is Circular Quay, so it would be like calling
> the S release Street for  Street.
> 
> Having said that there are not that many of them and Sydney people know
> what you mean when you are going to the Quay.
> 
> 
> On 14 July 2016 at 21:35, Neil Jerram  > wrote:
> 
> Not sure what the problem would be with 'Quay' or 'Street' - they
> both sound like good options to me.
> 
> 
> On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn  > wrote:
> 
> 
> 
> > >> Hey all!
> > >>
> > >> The poll emails for the P and Q naming have started to go
> out - and
> > >> we're experiencing some difficulties. Not sure at the
> moment what's
> > >> going on ... but we'll keep working on the issues and get
> ballots to
> > >> everyone as soon as we can.
> > >
> > > You'll need to re-send at least some emails, because the
> link I received
> > > is wrong - the site just reports
> > >
> > >   "Your voter key is invalid. You should have received a
> correct URL by
> > >   email."
> >
> > Yup. That would be a key symptom of the problems. One of the
> others is
> > that I just uploaded 3000 of the emails to the Q poll and it
> shows 0
> > active voters.
> >
> > I think maybe it needs a nap...
> 
> Any chance we could remove "Quay" from the Q release naming poll
> before
> the links are fixed and the real voting starts?
> 
> Otherwise we risk looking a bit silly, since "Quay" for the Q
> release
> would be somewhat akin to choosing "Street" for the S release ;)
> 
> Cheers,
> Eoghan
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


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

Re: [openstack-dev] [TripleO] 3rd party CI

[Steven Hardy]

On Thu, Jul 14, 2016 at 04:45:03PM -0400, Wesley Hayutin wrote:
>Greetings,
>Just wanted to let folks know we're bringing up two 3rd party gates for
>TripleO CI atm.
>1. The first gate will be for upgrading from mitaka -> newton/master
>2. The second gate will be for running TripleO CI on RHEL 7.2
>We're working out the logging for #2.  ATM we're going to try and store
>the logs on an openshift gear as we don't have a public file server
>available.  If anyone has a public server where we can store logs and
>would like to help, please let us know.
>If you have any questions please let us know.

This is good news, thanks for the update!

Our previous "upgrade" job never reached the point of actually testing full
major version upgrades, so it will be great to have coverage of that via
these jobs.

Also good news re RHEL, I was planning to remove RHEL from the docs[1],
because I've got some reports that the current docs don't work
(repo/package version issues) - I'll leave that patch WIP until we can
compare the docs with what's tested in CI and potentially fix them instead
of removing (if you can help with that it'd be much appreciated :)

Thanks!

Steve

[1] https://review.openstack.org/#/c/340503/

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

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

[Victor Stinner]

Hi,

Le 13/07/2016 à 21:17, Denis Makogon a écrit :

I have free capacity to work on porting code to Py3. So, if any PTL is
running out of team capacity i can help to work on project to enable Py3
support.


If you would like to help, you can try to run functional tests on 
DevStack. Begin with projects which have their unit tests already ported 
to Python 3.

https://wiki.openstack.org/wiki/Python3#Functional_and_Integration_Tests

Victor

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

[openstack-dev] [OPENSTACK] [HORIZON] Changing theme

[BIKRAMADITYA SAHOO]

Hi,

I am unable to change the theme for my openstack horizon. I tried with the
this  and
various other tutorial but i am still unable to achieve my goal.

I also want to have a custom "splash" (a complete custom login) and i am
unable to find any good tutorial.

I tried "local_settings.py" with following
CUSTOM_THEME_PATH="static/themes/production"
CUSTOM_THEME_PATH="themes/production"
CUSTOM_THEME_PATH="static/production"

"production" directory is present in
"/usr/share/openstack-dashboard/openstack_dashboard/static/themes" as well
as "/usr/share/openstack-dashboard/openstack_dashboard/static/custom"
directories.

Also i tried deleting the "i/usr/share/openstack-dashboard-ubuntu-theme"
and
"/usr/share/openstack-dashboard/openstack_dashboard/local/ubuntu_theme.py"
and still no use.

No matter what i do, horizon is loading images from "static/themes/ubuntu "
directory ("
http://controller/static/themes/ubuntu/image-background-pattern.png";).

Kindly point me to anything i am doing wrong or/and any well-documented
tutorial or docs.

NOTE: I want to have the above changes in an already running setup by
manipulating files.

Thanks and Regards,
Bikramaditya Sahoo
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO][release] TripleO Newton Release schedule and Feature Freeze

[Steven Hardy]

Hi all,

So we discussed $subject in our weekly meeting, and I wanted to follow up
with some proposals to clarify our plan wrt the final Newton release,
feature freeze, and how the dates will line up given that we're now
following[1] the cycle-trailing release model[2] for most TripleO
deliverables.

According to the official release schedule[3], the feature freeze for
most projects is aligned with the newton-3 milestone (August 29th) - I
suggest that we observe the same date for our Feature Freeze, but that we
also observe the normal process for feature freeze exceptions.

This means that we'll have a "release valve" in the event that we require
feature-orientated changes to TripleO near the end of the cycle
(integrating a new service that's disabled by default was mentioned as an
example in the meeting), but also that we'll enable greater control over
the nature of changes that are accepted towards the end of the cycle.

Note that the process is to email this list, with a description of the FFE
that is required, and a justification of why it's needed and low-risk.
We'll then discuss it and vote to accept or deny it (the closer we get to
the release the more likely we are to deny any exceptions due to the risk
of regressions).

Nearer the time I'll create RC milestones, which we can use to track
incremental releases (containing post newton-3 bugfixes and FFE features)
as we work towards our Newton final release.

After the main Newton coordinated release (planned for October 3rd) no feature
backports will be permitted, and we'll ship the TripleO final release
before the cycle-trailing deadline (October 17th, hopefully we'll release
sooner than that though provided all the packaging and puppet dependencies
are finished).

Also note that when we cut stable/newton we'll again be observing the
normal stable branch process[5], which means bugfixes only - no feature
backports will be permitted (same as we've done for stable/mitaka).

Hope that makes sense, please let me know if there are any comments,
concerns or questions!

Thanks!

Steve


[1] https://review.openstack.org/#/c/308236/
[2] 
https://github.com/openstack/governance/blob/master/reference/tags/release_cycle-trailing.rst
[3] http://releases.openstack.org/newton/schedule.html
[4] 
http://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
[5] http://docs.openstack.org/project-team-guide/stable-branches.html

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

Re: [openstack-dev] [nova][scheduler] A simple solution for better scheduler performance

[John Garbutt]

On 15 July 2016 at 09:26, Cheng, Yingxin  wrote:
> It is easy to understand that scheduling in nova-scheduler service consists 
> of 2 major phases:
> A. Cache refresh, in code [1].
> B. Filtering and weighing, in code [2].
>
> Couple of previous experiments [3] [4] shows that “cache-refresh” is the 
> major bottleneck of nova scheduler. For example, the 15th page of 
> presentation [3] says the time cost of “cache-refresh” takes 98.5% of time of 
> the entire `_schedule` function [6], when there are 200-1000 nodes and 50+ 
> concurrent requests. The latest experiments [5] in China Mobile’s 1000-node 
> environment also prove the same conclusion, and it’s even 99.7% when there’re 
> 40+ concurrent requests.
>
> Here’re some existing solutions for the “cache-refresh” bottleneck:
> I. Caching scheduler.
> II. Scheduler filters in DB [7].
> III. Eventually consistent scheduler host state [8].
>
> I can discuss their merits and drawbacks in a separate thread, but here I 
> want to show a simplest solution based on my findings during the experiments 
> [5]. I wrapped the expensive function [1] and tried to see the behavior of 
> cache-refresh under pressure. It is very interesting to see a single 
> cache-refresh only costs about 0.3 seconds. And when there’re concurrent 
> cache-refresh operations, this cost can be suddenly increased to 8 seconds. 
> I’ve seen it even reached 60 seconds for one cache-refresh under higher 
> pressure. See the below section for details.

I am curious about what DB driver you are using?
Using PyMySQL should remove at lot of those issues.
This is the driver we use in the gate now, but it didn't used to be the default.

If you use the C based MySQL driver, you will find it locks the whole
process when making a DB call, then eventlet schedules the next DB
call, etc, etc, and then it loops back and allows the python code to
process the first db call, etc. In extreme cases you will find the
code processing the DB query considers some of the hosts to be down
since its so long since the DB call was returned.

Switching the driver should dramatically increase the performance of (II)

> It raises a question in the current implementation: Do we really need a 
> cache-refresh operation [1] for *every* requests? If those concurrent 
> operations are replaced by one database query, the scheduler is still happy 
> with the latest resource view from database. Scheduler is even happier 
> because those expensive cache-refresh operations are minimized and much 
> faster (0.3 seconds). I believe it is the simplest optimization to scheduler 
> performance, which doesn’t make any changes in filter scheduler. Minor 
> improvements inside host manager is enough.

So it depends on the usage patterns in your cloud.

The caching scheduler is one way to avoid the cache-refresh operation
on every request. It has an upper limit on throughput as you are
forced into having a single active nova-scheduler process.

But the caching means you can only have a single nova-scheduler
process, where as (II) allows you to have multiple nova-scheduler
workers to increase the concurrency.

> [1] 
> https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L104
> [2] 
> https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L112-L123
> [3] 
> https://www.openstack.org/assets/presentation-media/7129-Dive-into-nova-scheduler-performance-summit.pdf
> [4] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098202.html
> [5] Please refer to Barcelona summit session ID 15334 later: “A tool to test 
> and tune your OpenStack Cloud? Sharing our 1000 node China Mobile experience.”
> [6] 
> https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L53
> [7] https://review.openstack.org/#/c/300178/
> [8] https://review.openstack.org/#/c/306844/
>
>
> ** Here is the discovery from latest experiments [5] **
> https://docs.google.com/document/d/1N_ZENg-jmFabyE0kLMBgIjBGXfL517QftX3DW7RVCzU/edit?usp=sharing
>
> The figure 1 illustrates the concurrent cache-refresh operations in a nova 
> scheduler service. There’re at most 23 requests waiting for the cache-refresh 
> operations at time 43s.
>
> The figure 2 illustrates the time cost of every requests in the same 
> experiment. It shows that the cost is increased with the growth of 
> concurrency. It proves the vicious circle that a request will wait longer for 
> the database when there’re more waiting requests.
>
> The figure 3/4 illustrate a worse case when the cache-refresh operation costs 
> reach 60 seconds because of excessive cache-refresh operations.

Sorry, its not clear to be if this was using I, II, or III? It seems
like its just using the default system?

This looks like the problems I have seen when you don't use PyMySQL
for your DB driver.

Thanks,
John

__
OpenStack Development Mailing List (not for usage questions

[openstack-dev] [heat][yaql] Heat map replacement options

[Steven Hardy]

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:

  map_replace:
template: {get_param: ServiceNetMap}
value_replacements: {get_param: NetIpMap}

The function could accept e.t value_replacements and key_replacements, and
simply iterate over the map doing a key lookup and replacement on the
key/value when they match.

Anyone got any simpler ideas, or an example of what this would look like in
yaql?

Thanks!

Steve

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

Re: [openstack-dev] [OPENSTACK] [HORIZON] Changing theme

[Radomir Dopieralski]

Did you forget to run collectstatic?

On Fri, Jul 15, 2016 at 10:00 AM, BIKRAMADITYA SAHOO <
ansh.ansh20...@gmail.com> wrote:

> Hi,
>
> I am unable to change the theme for my openstack horizon. I tried with the
> this  and
> various other tutorial but i am still unable to achieve my goal.
>
> I also want to have a custom "splash" (a complete custom login) and i am
> unable to find any good tutorial.
>
> I tried "local_settings.py" with following
> CUSTOM_THEME_PATH="static/themes/production"
> CUSTOM_THEME_PATH="themes/production"
> CUSTOM_THEME_PATH="static/production"
>
> "production" directory is present in
> "/usr/share/openstack-dashboard/openstack_dashboard/static/themes" as well
> as "/usr/share/openstack-dashboard/openstack_dashboard/static/custom"
> directories.
>
> Also i tried deleting the "i/usr/share/openstack-dashboard-ubuntu-theme"
> and
> "/usr/share/openstack-dashboard/openstack_dashboard/local/ubuntu_theme.py"
> and still no use.
>
> No matter what i do, horizon is loading images from "static/themes/ubuntu
> " directory ("
> http://controller/static/themes/ubuntu/image-background-pattern.png";).
>
> Kindly point me to anything i am doing wrong or/and any well-documented
> tutorial or docs.
>
> NOTE: I want to have the above changes in an already running setup by
> manipulating files.
>
> Thanks and Regards,
> Bikramaditya Sahoo
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OPENSTACK] [HORIZON] Changing theme

[BIKRAMADITYA SAHOO]

No, i did run it. In the first run it collected some files but later run it
didn't (maybe as it already collected).

Also after deleting "/us/share/openstack-dashboard-ubuntu-theme" if i run
collectstatic then it is giving error with
"/us/share/openstack-dashboard-ubuntu-theme/static/themes/ubuntu" not found

On Fri, Jul 15, 2016 at 2:59 PM, Radomir Dopieralski  wrote:

> Did you forget to run collectstatic?
>
> On Fri, Jul 15, 2016 at 10:00 AM, BIKRAMADITYA SAHOO <
> ansh.ansh20...@gmail.com> wrote:
>
>> Hi,
>>
>> I am unable to change the theme for my openstack horizon. I tried with
>> the this
>>  and
>> various other tutorial but i am still unable to achieve my goal.
>>
>> I also want to have a custom "splash" (a complete custom login) and i am
>> unable to find any good tutorial.
>>
>> I tried "local_settings.py" with following
>> CUSTOM_THEME_PATH="static/themes/production"
>> CUSTOM_THEME_PATH="themes/production"
>> CUSTOM_THEME_PATH="static/production"
>>
>> "production" directory is present in
>> "/usr/share/openstack-dashboard/openstack_dashboard/static/themes" as well
>> as "/usr/share/openstack-dashboard/openstack_dashboard/static/custom"
>> directories.
>>
>> Also i tried deleting the "i/usr/share/openstack-dashboard-ubuntu-theme"
>> and
>> "/usr/share/openstack-dashboard/openstack_dashboard/local/ubuntu_theme.py"
>> and still no use.
>>
>> No matter what i do, horizon is loading images from "static/themes/ubuntu
>> " directory ("
>> http://controller/static/themes/ubuntu/image-background-pattern.png";).
>>
>> Kindly point me to anything i am doing wrong or/and any well-documented
>> tutorial or docs.
>>
>> NOTE: I want to have the above changes in an already running setup by
>> manipulating files.
>>
>> Thanks and Regards,
>> Bikramaditya Sahoo
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OPENSTACK] [HORIZON] Changing theme

[BIKRAMADITYA SAHOO]

No, i did run it. In the first run it collected some files but later run it
didn't (maybe as it already collected).

Also after deleting "/us/share/openstack-dashboard-ubuntu-theme" if i run
collectstatic then it is giving error with
"/us/share/openstack-dashboard-ubuntu-theme/static/themes/ubuntu" not found

On Fri, Jul 15, 2016 at 2:59 PM, Radomir Dopieralski  wrote:

> Did you forget to run collectstatic?
>
> On Fri, Jul 15, 2016 at 10:00 AM, BIKRAMADITYA SAHOO <
> ansh.ansh20...@gmail.com> wrote:
>
>> Hi,
>>
>> I am unable to change the theme for my openstack horizon. I tried with
>> the this
>>  and
>> various other tutorial but i am still unable to achieve my goal.
>>
>> I also want to have a custom "splash" (a complete custom login) and i am
>> unable to find any good tutorial.
>>
>> I tried "local_settings.py" with following
>> CUSTOM_THEME_PATH="static/themes/production"
>> CUSTOM_THEME_PATH="themes/production"
>> CUSTOM_THEME_PATH="static/production"
>>
>> "production" directory is present in
>> "/usr/share/openstack-dashboard/openstack_dashboard/static/themes" as well
>> as "/usr/share/openstack-dashboard/openstack_dashboard/static/custom"
>> directories.
>>
>> Also i tried deleting the "i/usr/share/openstack-dashboard-ubuntu-theme"
>> and
>> "/usr/share/openstack-dashboard/openstack_dashboard/local/ubuntu_theme.py"
>> and still no use.
>>
>> No matter what i do, horizon is loading images from "static/themes/ubuntu
>> " directory ("
>> http://controller/static/themes/ubuntu/image-background-pattern.png";).
>>
>> Kindly point me to anything i am doing wrong or/and any well-documented
>> tutorial or docs.
>>
>> NOTE: I want to have the above changes in an already running setup by
>> manipulating files.
>>
>> Thanks and Regards,
>> Bikramaditya Sahoo
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Filter ComputeCapabilitiesFilter returned 0 hosts

[Turbo Fredriksson]

On Jul 14, 2016, at 11:15 PM, Brent Troge wrote:

> dont you have to set something like the below in your flavor ?
> 
> aggregate_instance_extra_specs:volume_type=ZOL


If you mean

properties:volume_type=ZOL

then yes. But is the "aggregate_instance_extra_specs" something
specific, or just "pseudo"?
--
Michael Jackson is not going to buried or cremated
but recycled into shopping bags so he can remain white,
plastic and dangerous for kids to play with.


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

Re: [openstack-dev] [Openstack] Naming polls - and some issues

[Eoghan Glynn]

> (top posting on purpose)
> 
> I have re-started the Q poll and am slowly adding all of you fine folks
> to it. Let's keep our fingers crossed that it works this time.
> 
> I also removed Quay. Somehow my brain didn't process the "it would be
> like naming the S release "Street"" when reading the original names.
> Based on the naming critera, "Circular Quay" would be a great option for
> "Circular" - but sadly we already named the C release Cactus. It's
> possible this choice will make someone unhappy, and if it does, I'm
> certainly sorry. On the other hand, there are _so_ many awesome names
> possible in this list, I don't think we'll miss it.

Excellent, thanks Monty for fixing this ... agreed that the remaining
Q* choices are more than enough.

Cheers,
Eoghan 

> I'll fire out new emails for P once Q is up and going.
> 
> On 07/15/2016 11:02 AM, Jamie Lennox wrote:
> > Partially because its name is Circular Quay, so it would be like calling
> > the S release Street for  Street.
> > 
> > Having said that there are not that many of them and Sydney people know
> > what you mean when you are going to the Quay.
> > 
> > 
> > On 14 July 2016 at 21:35, Neil Jerram  > > wrote:
> > 
> > Not sure what the problem would be with 'Quay' or 'Street' - they
> > both sound like good options to me.
> > 
> > 
> > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn  > > wrote:
> > 
> > 
> > 
> > > >> Hey all!
> > > >>
> > > >> The poll emails for the P and Q naming have started to go
> > out - and
> > > >> we're experiencing some difficulties. Not sure at the
> > moment what's
> > > >> going on ... but we'll keep working on the issues and get
> > ballots to
> > > >> everyone as soon as we can.
> > > >
> > > > You'll need to re-send at least some emails, because the
> > link I received
> > > > is wrong - the site just reports
> > > >
> > > >   "Your voter key is invalid. You should have received a
> > correct URL by
> > > >   email."
> > >
> > > Yup. That would be a key symptom of the problems. One of the
> > others is
> > > that I just uploaded 3000 of the emails to the Q poll and it
> > shows 0
> > > active voters.
> > >
> > > I think maybe it needs a nap...
> > 
> > Any chance we could remove "Quay" from the Q release naming poll
> > before
> > the links are fixed and the real voting starts?
> > 
> > Otherwise we risk looking a bit silly, since "Quay" for the Q
> > release
> > would be somewhat akin to choosing "Street" for the S release ;)
> > 
> > Cheers,
> > Eoghan
> > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 

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

Re: [openstack-dev] [neutron][qos][drivers] RFE about QoS extended validation

[Miguel Angel Ajo Pelayo]

Oh yikes, I was "hit by a plane" (delay) plus a huge jet lag and
didn't make it to the meeting, I'll be there next week. Thank you.

On Tue, Jul 12, 2016 at 9:48 AM, Miguel Angel Ajo Pelayo
 wrote:
> I'd like to ask for some prioritization on this RFE [1], since it's blocking
> one of the already existing RFEs for RFE (ingress bandwidth limiting),
> and we're trying to enhance the operator experience on the QoS service.
>
> It's been discussed on previous driver meetings, and it seems to have
> some consensus after some tweaks, so discussion shall be hopefully short.
>
> We also have a related -not necessary- spec, just for reference if somebody
> wants to sneak into the extended details [2], and even some initial
> implementation
> [3]
>
>
> Thank you for your time,
> Miguel Ángel Ajo
>
> [1] https://bugs.launchpad.net/neutron/+bug/1586056
> [2] https://review.openstack.org/#/c/323474/
> [3] https://review.openstack.org/#/c/319694/

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

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Kashyap Chamarthy]

On Thu, Jul 14, 2016 at 03:19:39PM -0500, Matt Riedemann wrote:
> On 7/14/2016 11:34 AM, Paul Bourke wrote:
> > Hi Matt,
> > 
> > Here is the failure from nova_compute on trying to start an instance:

[...]

> > 2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR
> > oslo_service.service migration_flags &=
> > ~libvirt.VIR_MIGRATE_AUTO_CONVERGE
> > 2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR
> > oslo_service.service AttributeError: 'module' object has no attribute
> > 'VIR_MIGRATE_AUTO_CONVERGE'
> > 
> > The full log can be viewed at
> > http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-source/0849a74/console.html#_2016-07-13_18_04_12_526704

[...]

> > > What version of libvirt/qemu do you have in the image/job you're running?
> > > 
> > > See:
> > > 
> > > https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L278
> > > 
> > > If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
> > > get these values from libvirt:
> > > 
> > > https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029495a6/nova/virt/libvirt/driver.py#L633

Looking at the versions noted by Paul[1] in the upthread, they've
satisfied the above requirements.

> > > 
> > > Could be something patched out of the versions you're using from the
> > > distro maybe?

Yeah, I too wonder this could be it, because, see [*]
> > > 
> > > The actual failure paste/trace would help.
> > > 

[...]

> Looks like you have the minimum versions of libvirt and qemu required for
> VIR_MIGRATE_AUTO_CONVERGE but for whatever reason it's not actually in
> libvirt in the image you're testing against.
> 
> I'm not sure it would matter, but what version of libvirt-python is being
> used?

[*]

I extracted the contents of the said python-libvirt .deb from here:

$ wget 
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-staging/+files/python-libvirt_1.3.1-1ubuntu1~cloud0_amd64.deb
$ ar vx python-libvirt_1.3.1-1ubuntu1~cloud0_amd64.deb
$ tar -xvf  data.tar.xz

And you do see VIR_MIGRATE_AUTO_CONVERGE attribute as part of
virDomainMigrateFlags():

$ cd usr/
$ grep -r VIR_MIGRATE_AUTO_CONVERGE
lib/python2.7/dist-packages/libvirt.py:VIR_MIGRATE_AUTO_CONVERGE = 8192


So, the said attribute is certainly present in the python-libvirt version
they're using.

> I'd probably ping danpb or kashyap about this in #openstack-nova in IRC.

-- 
/kashyap

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

Re: [openstack-dev] [Openstack] Filter ComputeCapabilitiesFilter returned 0 hosts

[Brent Troge]

When I setup my host aggregates, and want to direct a flavor to a specific
aggregate  I use the following steps.

nova aggregate-set-metadata aggregate1 hiperf=true
nova flavor-key  flavor1 set aggregate_instance_extra_specs:hiperf=true

in your case..

nova aggregate-set-metadata zfs volume_type=ZOL
nova flavor-key  z1.3small set
aggregate_instance_extra_specs:volume_type=ZOL


On Fri, Jul 15, 2016 at 4:47 AM, Turbo Fredriksson  wrote:

> On Jul 14, 2016, at 11:15 PM, Brent Troge wrote:
>
> > dont you have to set something like the below in your flavor ?
> >
> > aggregate_instance_extra_specs:volume_type=ZOL
>
>
> If you mean
>
> properties:volume_type=ZOL
>
> then yes. But is the "aggregate_instance_extra_specs" something
> specific, or just "pseudo"?
> --
> Michael Jackson is not going to buried or cremated
> but recycled into shopping bags so he can remain white,
> plastic and dangerous for kids to play with.
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][yaql] Heat map replacement options

[Peter Razumovsky]

Try this:

yaql:
  expression:let(root => $) ->
dict($root.data.service.items().select([$[0], $root.data.ip[$[1]]]))
  data:
service: { get_param: ServiceNetMap }
ip: { get_param: NetIpMap}


2016-07-15 12:25 GMT+03:00 Steven Hardy :

> 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:
>
>   map_replace:
> template: {get_param: ServiceNetMap}
> value_replacements: {get_param: NetIpMap}
>
> The function could accept e.t value_replacements and key_replacements, and
> simply iterate over the map doing a key lookup and replacement on the
> key/value when they match.
>
> Anyone got any simpler ideas, or an example of what this would look like in
> yaql?
>
> Thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Peter Razumovsky
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][yaql] Heat map replacement options

[Steven Hardy]

On Fri, Jul 15, 2016 at 03:35:51PM +0300, Peter Razumovsky wrote:
>Try this:
>yaql:
>  expression:let(root => $) ->
>dict($root.data.service.items().select([$[0], $root.data.ip[$[1]]]))
>  data:
>    service: { get_param: ServiceNetMap }
>    ip: { get_param: NetIpMap}

That works, thanks! :)

Steve

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

[openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

[Andrey Sledzinskiy]

Hi,
I'd like to nominate Alexey Stepanov for fuel-qa [0] and fuel-devops [1]
core.

Alexey is doing great job improving fuel-qa and fuel-devops projects.
He's become an expert in code base in very short terms so I think he
deserves to be a part of fuel-qa/fuel-devops core team.

Please, vote for Alexey!

[0]
http://stackalytics.com/?release=all&module=fuel-qa&user_id=astepanov-m&metric=marks
[1]
http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=marks

-- 
Thanks,
Andrey Sledzinskiy
QA Engineer,
Mirantis, Kharkiv
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

[Anastasia Urlapova]

+1

On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy <
asledzins...@mirantis.com> wrote:

> Hi,
> I'd like to nominate Alexey Stepanov for fuel-qa [0] and fuel-devops [1]
> core.
>
> Alexey is doing great job improving fuel-qa and fuel-devops projects.
> He's become an expert in code base in very short terms so I think he
> deserves to be a part of fuel-qa/fuel-devops core team.
>
> Please, vote for Alexey!
>
> [0]
> http://stackalytics.com/?release=all&module=fuel-qa&user_id=astepanov-m&metric=marks
> [1]
> http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=marks
>
> --
> Thanks,
> Andrey Sledzinskiy
> QA Engineer,
> Mirantis, Kharkiv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Project Mascot

[Jesse Pretorius]

Hi everyone,

As discussed in the community meeting yesterday [1] the foundation wishes each 
project to select a mascot for the project [2][3]. The mascot needs to be 
appropriate (please read the links for the constraints) and in some way linked 
to the project. We need to come up with a list of 3-5 options.

Options discussed and agreed as appropriate in the meeting yesterday:

  1.  A Bull (links directly to Ansible’s mascot, although ours can be 
different).
  2.  A Cape Buffalo (distinctive, and reasonably close to a Bull).

Please consider and reply with more options, explaining the link to the project 
so that we can all discuss the options at the next meeting to finalise our list.

[1] 
http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-07-14-15.58.log.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
[3] http://www.openstack.org/project-mascots

Thanks,

Jesse
IRC: odyssey4me




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

[Bulat Gaifullin]

+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 15 Jul 2016, at 16:08, Anastasia Urlapova  wrote:
> 
> +1
> 
> On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy 
> mailto:asledzins...@mirantis.com>> wrote:
> Hi,
> I'd like to nominate Alexey Stepanov for fuel-qa [0] and fuel-devops [1] core.
> 
> Alexey is doing great job improving fuel-qa and fuel-devops projects. 
> He's become an expert in code base in very short terms so I think he deserves 
> to be a part of fuel-qa/fuel-devops core team.  
> 
> Please, vote for Alexey!
> 
> [0] 
> http://stackalytics.com/?release=all&module=fuel-qa&user_id=astepanov-m&metric=marks
>  
> 
> [1] 
> http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=marks
>  
> 
> 
> -- 
> Thanks, 
> Andrey Sledzinskiy  
> QA Engineer, 
> Mirantis, Kharkiv
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

[Tatyana Leontovich]

+1

On Fri, Jul 15, 2016 at 4:08 PM, Anastasia Urlapova 
wrote:

> +1
>
> On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy <
> asledzins...@mirantis.com> wrote:
>
>> Hi,
>> I'd like to nominate Alexey Stepanov for fuel-qa [0] and fuel-devops [1]
>> core.
>>
>> Alexey is doing great job improving fuel-qa and fuel-devops projects.
>> He's become an expert in code base in very short terms so I think he
>> deserves to be a part of fuel-qa/fuel-devops core team.
>>
>> Please, vote for Alexey!
>>
>> [0]
>> http://stackalytics.com/?release=all&module=fuel-qa&user_id=astepanov-m&metric=marks
>> [1]
>> http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=marks
>>
>> --
>> Thanks,
>> Andrey Sledzinskiy
>> QA Engineer,
>> Mirantis, Kharkiv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] our mascot - input needed

[Miles Gould]

On 15/07/16 03:53, Britt Houser (bhouser) wrote:

Koala is the best by a long shot. These ideas are all total stretches:
  Bee on a honeycomb – Its kinda like the bee is orchestrating
containers of honey.


That sounds more like a honeypot ant to me:
https://en.wikipedia.org/wiki/Honeypot_ant
https://www.youtube.com/watch?v=5rwDdWBIXIg

I think Ironic has dibs on using a bear, but you're probably OK with a 
koala since they're really marsupials :-)


Miles

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

[openstack-dev] [release][documentation][telemetry][murano][trove] missing milestones

[Doug Hellmann]

We have a few deliverables without any milestone tags for this
release cycle, yet (see the list below). They are at risk of being
excluded from the final release for failing to prepare releases
under the cycle-with-milestone release model.

Please propose 0b2 tags by the end of the day, or let us know
officially that you do not intend to include these deliverables
this cycle.

Thanks,
Doug

training-labs (Documentation)
aodh (Telemetry)
ceilometer (Telemetry)
murano-apps (murano)
trove-image-builder (trove)

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

Re: [openstack-dev] [release][documentation][telemetry][murano][trove] missing milestones

[Amrith Kumar]

Doug,

At this time it is highly unlikely that there will be a 0b2 tag on 
trove-image-builder.

I may get to a 0b3 tag but per the proposed membership freeze[1], we have 
missed two of the milestones and therefore trove-image-builder will likely not 
be included in the newton release.

Thanks,

-amrith

[1] https://review.openstack.org/#/c/339833/

> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Friday, July 15, 2016 9:37 AM
> To: openstack-dev 
> Subject: [openstack-dev]
> [release][documentation][telemetry][murano][trove] missing milestones
> 
> We have a few deliverables without any milestone tags for this
> release cycle, yet (see the list below). They are at risk of being
> excluded from the final release for failing to prepare releases
> under the cycle-with-milestone release model.
> 
> Please propose 0b2 tags by the end of the day, or let us know
> officially that you do not intend to include these deliverables
> this cycle.
> 
> Thanks,
> Doug
> 
> training-labs (Documentation)
> aodh (Telemetry)
> ceilometer (Telemetry)
> murano-apps (murano)
> trove-image-builder (trove)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core

[Artem Panchenko]

+1

On 15.07.16 16:25, Tatyana Leontovich wrote:

+1

On Fri, Jul 15, 2016 at 4:08 PM, Anastasia Urlapova 
mailto:aurlap...@mirantis.com>> wrote:


+1

On Fri, Jul 15, 2016 at 4:02 PM, Andrey Sledzinskiy
mailto:asledzins...@mirantis.com>> wrote:

Hi,
I'd like to nominate Alexey Stepanovfor fuel-qa [0] and
fuel-devops [1] core.

Alexey is doing great job improving fuel-qa and fuel-devops
projects.
He's become an expert in code base in very short terms so I
think he deserves to be a part of fuel-qa/fuel-devops core team.

Please, vote for Alexey!

[0]

http://stackalytics.com/?release=all&module=fuel-qa&user_id=astepanov-m&metric=marks

[1]

http://stackalytics.com/?release=all&module=fuel-devops&user_id=astepanov-m&metric=marks


-- 
Thanks,

Andrey Sledzinskiy
QA Engineer,
Mirantis, Kharkiv


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


--
Artem Panchenko
QA Engineer

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

Re: [openstack-dev] [openstack-ansible] Project Mascot

[Matt Thompson]

Hi Jesse,

I like the idea of a water buffalo, as they're working animals used in
farming etc.  This links nicely to the project as these animals 'do the
heavy lifting', so to speak.  An ox, etc. could be another appropriate
mascot.

--Matt


On Fri, Jul 15, 2016 at 2:15 PM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> Hi everyone,
>
> As discussed in the community meeting yesterday [1] the foundation wishes
> each project to select a mascot for the project [2][3]. The mascot needs to
> be appropriate (please read the links for the constraints) and in some way
> linked to the project. We need to come up with a list of 3-5 options.
>
> Options discussed and agreed as appropriate in the meeting yesterday:
>
>1. A Bull (links directly to Ansible’s mascot, although ours can be
>different).
>2. A Cape Buffalo (distinctive, and reasonably close to a Bull).
>
> Please consider and reply with more options, explaining the link to the
> project so that we can all discuss the options at the next meeting to
> finalise our list.
>
> [1]
> http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-07-14-15.58.log.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
> [3] http://www.openstack.org/project-mascots
>
> Thanks,
>
> Jesse
> IRC: odyssey4me
>
>
> 
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][docs] API sprint results

[Steve Martinelli]

First of all, thanks to everyone who participated, the API sprint was a
huge success. We've converted nearly all of our old APIs (published on
specs.openstack.org) over to the proper API site (
http://developer.openstack.org/api-ref.html). We've got a few patches in
flight, and a few TODOs that haven't begun yet, but things are looking
positive. The end result of this is: we will no longer be publishing APIs
to specs.openstack.org and we'll place our existing ones in an `attic`
folder.

By the numbers:
- 10 unique patch authors
- 40 patches merged
- 8 patches in progress

We used the `keystone-api-sprint` topic:
https://review.openstack.org/#/q/topic:keystone-api-sprint

Here's the etherpad we used, which contains more detail:
https://etherpad.openstack.org/p/keystone-api-sprint

Again, thanks to everyone who wrote and reviewed patches for this effort.

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

Re: [openstack-dev] [keystone][docs] API sprint results

[Anne Gentle]

Congrats to the team, what an effort! Thanks so much for putting this together.

Anne

On Fri, Jul 15, 2016 at 9:08 AM, Steve Martinelli
 wrote:
> First of all, thanks to everyone who participated, the API sprint was a huge
> success. We've converted nearly all of our old APIs (published on
> specs.openstack.org) over to the proper API site
> (http://developer.openstack.org/api-ref.html). We've got a few patches in
> flight, and a few TODOs that haven't begun yet, but things are looking
> positive. The end result of this is: we will no longer be publishing APIs to
> specs.openstack.org and we'll place our existing ones in an `attic` folder.
>
> By the numbers:
> - 10 unique patch authors
> - 40 patches merged
> - 8 patches in progress
>
> We used the `keystone-api-sprint` topic:
> https://review.openstack.org/#/q/topic:keystone-api-sprint
>
> Here's the etherpad we used, which contains more detail:
> https://etherpad.openstack.org/p/keystone-api-sprint
>
> Again, thanks to everyone who wrote and reviewed patches for this effort.
>
> stevemar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
www.justwriteclick.com

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

[openstack-dev] [monasca] Announcing Monasca Analytics

[Vaquero Gonzalez, Luis Miguel]

Dear all,

I have the pleasure to introduce you to Monasca analytics, a seamless extension 
of Monanas that enables sharing of infrastructure analytic  recipes across the 
community.

Some of you are probably already familiar with it after we, in a 
"well-orchestrated marketing campaign", pushed 200 commits in one go, making 
Mr. Jenkins very upset.

The time has come to get you back some of your time and speed up complex and 
tedious error finding tasks that can be partially automated and shared in the 
community to make our lives a bit easier.

We are super excited about being part of the OpenStack community.

In the meantime, please feel free to have a look and start contributing :) or 
asking questions!!

https://github.com/openstack/monasca-analytics

Best regards,

Monasca-analytics team


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

[openstack-dev] [release] Release countdown for week R-11, July 18-22

[Doug Hellmann]

Focus
-

Major feature work should be well under way as we pass the second
milestone.

General Notes
-

Keep in mind that we freeze releases of all libraries between the third
milestone and the final release to give downstream packagers time to vet
the libraries. Only emergency bug fix updates are allowed during that
period, not releases for FFEs. Prioritize any feature work that includes
work in libraries to ensure that it can be completed and the library
released before the freeze.

Release Actions
---

A few projects have not yet submitted their newton-2 milestone tag. See
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099335.html
for details.

Important Dates
---

Library release freeze date starting R-6, Aug 25.

Newton 3 milestone, Sept 1

Newton release schedule: http://releases.openstack.org/newton/schedule.html

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

[openstack-dev] [nova][scheduler] Capability Modeling - Newton Mid-cycle Status

[Ed Leafe]

The current focus of improving the Nova Scheduler is progressing, with 
ResourceProviders now representing the quantities of the different resources 
available for virtualization. But these resources also have varying qualities 
that are not consumed by a VM, but describe something about the resource. The 
most common example is disk space, which can be consumed. This disk space can 
be either spinning disk or SSD, so we need to find a way to a) represent that 
quality and b) allow to user to specify those qualities that they desire.

We are proposing to add qualities to a ResourceProvider through the use of tags 
[0]. These tags are bits of text that can represent the qualities of that 
ResourceProvider, which can be queried in order to find those resources that 
have the desired qualities. In the example above, a host with SSD disk storage 
would have the tags ‘compute’ and ‘sad’ (among others), which would be queried 
for if the user asks for a VM backed by SSD.

The way that a user makes such a request will be changing, too. Instead of 
cramming all the possible qualitative aspects of a resource into a flavor, in 
the poorly-name ‘extra_specs’, the use of qualitative tags will allow flavors 
to be greatly simplified. In order to specify those qualitative aspects in a 
request, the API will add two new multi-value keys to the server request body: 
‘requirements’ and ‘preferences’ [1]. As the names suggest, any quality 
specified in the requirements key must be present in the ResourceProvider, 
while any quality in the preferences key *may* will be used to select, but not 
disqualify, a host. In practical terms, if you specify ‘ssd’ as a requirement, 
you are guaranteed that the VM you get will have SSD, or the request will fail. 
With ‘ssd’ as a preference, though, you are not guaranteed that the VM you get 
will have SSD, but if any are available, you will get SSD.

Many host capabilities can be retrieved from the virt layer, and there is a 
proposal [2] to add a new virt method to retrieve those from the hypervisor. 
These can be exposed via the API, or be used to automatically tag the host’s 
ResourceProvider record with the appropriate tags. Some more work needs to be 
done to determine how to best represent the different combinations of hardware 
and hypervisor capabilities into something that can be standardized as much as 
possible (for cross-cloud interop) without severely limiting the flexibility of 
the design (to keep current). One such proposal along these lines [3] is to 
standardize these capabilities into a set of defined enums. Again, the concern 
is the trade-off of cloud interop vs. flexibility, as defining enums in code 
means that adding a new capability will require a code change, along with the 
necessary doc changes and review.

So we certainly have enough to discuss next week at the mid-cycle!

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099032.html
[1] https://review.openstack.org/313784
[2] https://review.openstack.org/#/c/286520
[3] https://review.openstack.org/#/c/309762

-- Ed Leafe






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

Re: [openstack-dev] [release][documentation][telemetry][murano][trove] missing milestones

[Kirill Zaitsev]

We’re in the process of tearing down murano apps into separate production grade 
apps and murano-examples, that are only good as, well examples. So we do not 
intend to include murano-apps as a deliverable in this cycle. (Would probably 
need to update the release model for it as soon as possible next cycle)

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

On 15 juillet 2016 at 16:38:06, Doug Hellmann (d...@doughellmann.com) wrote:

We have a few deliverables without any milestone tags for this  
release cycle, yet (see the list below). They are at risk of being  
excluded from the final release for failing to prepare releases  
under the cycle-with-milestone release model.  

Please propose 0b2 tags by the end of the day, or let us know  
officially that you do not intend to include these deliverables  
this cycle.  

Thanks,  
Doug  

training-labs (Documentation)  
aodh (Telemetry)  
ceilometer (Telemetry)  
murano-apps (murano)  
trove-image-builder (trove)  

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


signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Python 35 jobs currently broken (was Re: New Python35 Jobs coming)

[Julien Danjou]

On Wed, Jul 06 2016, Andreas Jaeger wrote:

> New images for Xenial have been build and have been uploaded, first
> tests are passing. You should now be able to check python35 jobs for
> anything that's starting now.

Do we need to do anything to move the job to voting, or will this happen
automagically?

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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

Re: [openstack-dev] [openstack-ansible] Project Mascot

[Truman, Travis]

I like the bull, cape buffalo and oxen ideas. Any would work well for us.

From: Matt Thompson mailto:watering...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, July 15, 2016 at 9:49 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [openstack-ansible] Project Mascot

Hi Jesse,

I like the idea of a water buffalo, as they're working animals used in farming 
etc.  This links nicely to the project as these animals 'do the heavy lifting', 
so to speak.  An ox, etc. could be another appropriate mascot.

--Matt


On Fri, Jul 15, 2016 at 2:15 PM, Jesse Pretorius 
mailto:jesse.pretor...@rackspace.co.uk>> wrote:
Hi everyone,

As discussed in the community meeting yesterday [1] the foundation wishes each 
project to select a mascot for the project [2][3]. The mascot needs to be 
appropriate (please read the links for the constraints) and in some way linked 
to the project. We need to come up with a list of 3-5 options.

Options discussed and agreed as appropriate in the meeting yesterday:

  1.  A Bull (links directly to Ansible's mascot, although ours can be 
different).
  2.  A Cape Buffalo (distinctive, and reasonably close to a Bull).

Please consider and reply with more options, explaining the link to the project 
so that we can all discuss the options at the next meeting to finalise our list.

[1] 
http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-07-14-15.58.log.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
[3] http://www.openstack.org/project-mascots

Thanks,

Jesse
IRC: odyssey4me




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at 
www.rackspace.co.uk/legal/privacy-policy
 - This e-mail message may contain confidential or privileged information 
intended for the recipient. Any dissemination, distribution or copying of the 
enclosed material is prohibited. If you receive this transmission in error, 
please notify us immediately by e-mail at 
ab...@rackspace.com and delete the original 
message. Your cooperation is appreciated.

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


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

[openstack-dev] [nova] notification subteam meeting rescheduled to biweekly

[Balázs Gibizer]

Hi, 

As agreed on the last notification subteam meeting [1] I proposed to reschedule 
the subteam meeting to biweekly [2] as the workload is decreased due to non 
priority feature freeze. 
So the next notification subteam meeting will be held on 2016.07.26 17:00 UTC 
[1] on #openstack-meeting-4. [3]

Cheers,
Gibi

[1] 
http://eavesdrop.openstack.org/meetings/nova_notification/2016/nova_notification.2016-07-12-17.00.log.html
 
[2] https://review.openstack.org/#/c/342916/ 
[3] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160726T17 

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

Re: [openstack-dev] Mascot/logo for your project

[Julien Danjou]

On Mon, Jul 11 2016, Heidi Joy Tretheway wrote:

> 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.

Something is very unclear (but I'm getting used to it lol): are theses
logo created for projects or teams?

We have 4 different projects (Aodh, Gnocchi, Ceilometer & Panko) in the
Telemetry team. Should we have one or 4 mascots?

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Jay Pipes]

Kevin, can you please be *specific* about your complaints below? Saying 
things like "less project communication" and "projects not working 
together because of fear of adding dependencies" and "worse user 
experience" are your personal opinions. Please back those opinions up 
with specific examples of what you are talking about so that we may 
address specific things and not vague ideas.


Also, the overall goal of the Big Tent, as I've said repeatedly and 
people keep willfully ignoring, was *not* to "make the community more 
inclusive". It was to replace the inconsistently-applied-by-the-TC 
*subjective* criteria for project applications to OpenStack with an 
*objective* list of application requirements that could be 
*consistently* reviewed by the TC.


Thanks,
-jay

On 07/14/2016 01:30 PM, Fox, Kevin M wrote:

I'm going to go ahead and ask the difficult question now as the answer is 
relevant to the attached proposal...

Should we reconsider whether the big tent is the right approach going forward?

There have been some major downsides I think to the Big Tent approach, such as:
  * Projects not working together because of fear of adding extra dependencies 
Ops don't already have
  * Reimplementing features, badly, over and over again in different projects 
instead of standardizing something.
  * More projects being created due to politics and not technical reasons.
  * Less cross project communication
  * Greater Operator pain at trying to assemble a more loose confederation of 
projects into something useful.
  * General pushing off more and more work to Operators/Users to deal with.
  * Worse User experience as cross project issues aren't being addressed.
  * Previously incubated projects such as Nova, Swift, etc getting a 
disproportionate say in things as they have a greater current user base, and 
its increasingly hard now for new projects to gain any traction.
  * Much less community pressure on projects to work together to elevate 
everyone. Architectural decisions are now made at individual project level with 
little done at the OpenStack level.
  * etc...

The overall goal of the Big Tent was to make the community more inclusive. That 
I think has mostly happened. Which is good. But It also seems to have fractured 
the community more into insular islands and made the system harder for our 
operators/users. Which is bad.

Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its 
probably time to consider if it has been a net positive and should be further 
refined to try and address some of these problems, or a net negative and 
different approaches be explored.

Thanks,
Kevin

From: Hayes, Graham [graham.ha...@hpe.com]
Sent: Thursday, July 14, 2016 12:21 PM
To: OpenStack Development Mailing List (not for usage questions); 
openstack...@lists.openstack.org
Subject: [openstack-dev] [tc][all] Plugins for all

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big

Re: [openstack-dev] [nova][scheduler] A simple solution for better scheduler performance

[Cheng, Yingxin]

Hi John,

Thanks for the reply.

There’re two rounds of experiments:
Experiment A [3] is deployed by devstack. There’re 1000 compute services with 
fake virt driver. The DB driver is the devstack default PyMySQL. And the 
scheduler driver is the default filter scheduler.
Experiment B [4] is the real production environment from China Mobile with 
about 600 active compute nodes. The DB driver is the default driver of 
SQLAlchemy, i.e. the C based python-mysql. The scheduler is also filter 
scheduler.

And in analysis 
https://docs.google.com/document/d/1N_ZENg-jmFabyE0kLMBgIjBGXfL517QftX3DW7RVCzU/edit?usp=sharing
 Figure 1/2 are from experiment B, figure 3/4 are from experiment A. So the 2 
kinds of DB APIs are all covered.

My point is simple: When the host manager is querying host states for request 
A, and another request B comes, the host manager won’t launch a second 
cache-refresh; Instead, it simply reuses the first one and returns the same 
result to both A and B. In this way, we can reduce the expensive cache-refresh 
queries to minimum while keeping scheduler host states fresh. It will become 
more effective when there’re more compute nodes and heavier request pressure.

I also have runnable code that can better explain my idea: 
https://github.com/cyx1231st/making-food 

-- 
Regards
Yingxin

On 7/15/16, 17:19, "John Garbutt"  wrote:

On 15 July 2016 at 09:26, Cheng, Yingxin  wrote:
> It is easy to understand that scheduling in nova-scheduler service 
consists of 2 major phases:
> A. Cache refresh, in code [1].
> B. Filtering and weighing, in code [2].
>
> Couple of previous experiments [3] [4] shows that “cache-refresh” is the 
major bottleneck of nova scheduler. For example, the 15th page of presentation 
[3] says the time cost of “cache-refresh” takes 98.5% of time of the entire 
`_schedule` function [6], when there are 200-1000 nodes and 50+ concurrent 
requests. The latest experiments [5] in China Mobile’s 1000-node environment 
also prove the same conclusion, and it’s even 99.7% when there’re 40+ 
concurrent requests.
>
> Here’re some existing solutions for the “cache-refresh” bottleneck:
> I. Caching scheduler.
> II. Scheduler filters in DB [7].
> III. Eventually consistent scheduler host state [8].
>
> I can discuss their merits and drawbacks in a separate thread, but here I 
want to show a simplest solution based on my findings during the experiments 
[5]. I wrapped the expensive function [1] and tried to see the behavior of 
cache-refresh under pressure. It is very interesting to see a single 
cache-refresh only costs about 0.3 seconds. And when there’re concurrent 
cache-refresh operations, this cost can be suddenly increased to 8 seconds. 
I’ve seen it even reached 60 seconds for one cache-refresh under higher 
pressure. See the below section for details.

I am curious about what DB driver you are using?
Using PyMySQL should remove at lot of those issues.
This is the driver we use in the gate now, but it didn't used to be the 
default.

If you use the C based MySQL driver, you will find it locks the whole
process when making a DB call, then eventlet schedules the next DB
call, etc, etc, and then it loops back and allows the python code to
process the first db call, etc. In extreme cases you will find the
code processing the DB query considers some of the hosts to be down
since its so long since the DB call was returned.

Switching the driver should dramatically increase the performance of (II)

> It raises a question in the current implementation: Do we really need a 
cache-refresh operation [1] for *every* requests? If those concurrent 
operations are replaced by one database query, the scheduler is still happy 
with the latest resource view from database. Scheduler is even happier because 
those expensive cache-refresh operations are minimized and much faster (0.3 
seconds). I believe it is the simplest optimization to scheduler performance, 
which doesn’t make any changes in filter scheduler. Minor improvements inside 
host manager is enough.

So it depends on the usage patterns in your cloud.

The caching scheduler is one way to avoid the cache-refresh operation
on every request. It has an upper limit on throughput as you are
forced into having a single active nova-scheduler process.

But the caching means you can only have a single nova-scheduler
process, where as (II) allows you to have multiple nova-scheduler
workers to increase the concurrency.

> [1] 
https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L104
> [2] 
https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L112-L123
> [3] 
https://www.openstack.org/assets/presentation-media/7129-Dive-into-nova-scheduler-performance-summit.pdf
> [4] 
http://lists.openstack.org/pipermail/openstack-dev/2016-June/

[openstack-dev] [tripleo] service validation during deployment steps

[Emilien Macchi]

Hi,

Some people on the field brought interesting feedback:

"As a TripleO User, I would like the deployment to stop immediately
after an resource creation failure during a step of the deployment and
be able to easily understand what service or resource failed to be
installed".

Example:
If during step4 Puppet tries to deploy Neutron and OVS, but OVS fails
to start for some reasons, deployment should stop at the end of the
step.

So there are 2 things in this user story:

1) Be able to run some service validation within a step deployment.
Note about the implementation: make the validation composable per
service (OVS, nova, etc) and not per role (compute, controller, etc).

2) Make this information readable and easy to access and understand
for our users.

I have a proof-of-concept for 1) and partially 2), with the example of
OVS: https://review.openstack.org/#/c/342202/
This patch will make sure OVS is actually usable at step 4 by running
'ovs-vsctl show' during the Puppet catalog and if it's working, it
will create a Puppet anchor. This anchor is currently not useful but
could be in future if we want to rely on it for orchestration.
I wrote the service validation in Puppet 2 years ago when doing Spinal
Stack with eNovance:
https://github.com/openstack/puppet-openstacklib/blob/master/manifests/service_validation.pp
I think we could re-use it very easily, it has been proven to work.
Also, the code is within our Puppet profiles, so it's by design
composable and we don't need to make any connection with our current
services with some magic. Validation will reside within Puppet
manifests.
If you look my PoC, this code could even live in puppet-vswitch itself
(we already have this code for puppet-nova, and some others).

Ok now, what if validation fails?
I'm testing it here: https://review.openstack.org/#/c/342205/
If you look at /var/log/messages, you'll see:

Error: 
/Stage[main]/Tripleo::Profile::Base::Neutron::Ovs/Openstacklib::Service_validation[openvswitch]/Exec[execute
openvswitch validation]/returns: change from notrun to 0 failed

So it's pretty clear by looking at logs that openvswitch service
validation failed and something is wrong. You'll also notice in the
logs that deployed stopped at step 4 since OVS is not considered to
run.
It's partially addressing 2) because we need to make it more explicit
and readable. Dan Prince had the idea to use
https://github.com/ripienaar/puppet-reportprint to print a nice report
of Puppet catalog result (we haven't tried it yet). We could also use
Operational Tools later to monitor Puppet logs and find Service
validation failures.


So this email is a bootstrap of discussion, it's open for feedback.
Don't take my PoC as something we'll implement. It's an idea and I
think it's worth to look at it.
I like it for 2 reasons:
- the validation code reside within our profiles, so it's composable by design.
- it's flexible and allow us to test everything. It can be a bash
script, a shell command, a Puppet resource (provider, service, etc).

Thanks for reading so far,
-- 
Emilien Macchi

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 14/07/2016 21:20, Matt Riedemann wrote:
> On 7/14/2016 2:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>> It undoubtedly will cause more, but it is closer to our goal
>> of Recognizing all our community is part of OpenStack, and
>> differentiate projects by tags.
>>
>> This won't be a change that happens tomorrow, next week, or even next
>> cycle, but think as a goal, we should start moving in this direction
>> as soon as we can, and start building momentum.
>>
>> Thanks,
>>
>> Graham
>>
>> 0 - https://review.openstack.org/342366
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Just for my own understanding, are you suggesting that something like
> nova, cinder or neutron become optional for an openstack cloud?

Not in this proposal. (but that is an interesting idea we should follow
up on at a later date)

> And does this also include plugins within projects, like storage
> backends in cinder and hypervisor drivers in nova?

This is aimed at cross project interaction. So, if there is a project in
projects.yaml that is a backend, or a hypervisor driver, it should.

However, in the proposal, there is a choice that projects can make -
all in tree, or all plugins. The point of the proposal is equality of
access for the community.

What would that mean in practice for Nova? Nothing would really change
- they have decided to do in tree.

99% of deliverables tagged type:service will have no impact from this,
the change will be in projects that are used by  teams across the
community (CLI, Docs, UI etc), and provide a way for these projects
to integrate with them.

These integration points should be the same for *all* projects.

> Nova has been pushing for a few releases now on getting rid of plug
> points since they are barriers to interoperability.

Well, nova's plugins were barriers to interoperability, for other
projects they are the only mechanism for interoperability.


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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Hayes, Graham]

On 14/07/2016 21:33, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is 
> relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such 
> as:
>  * Projects not working together because of fear of adding extra dependencies 
> Ops don't already have
>  * Reimplementing features, badly, over and over again in different projects 
> instead of standardizing something.
>  * More projects being created due to politics and not technical reasons.
>  * Less cross project communication
>  * Greater Operator pain at trying to assemble a more loose confederation of 
> projects into something useful.
>  * General pushing off more and more work to Operators/Users to deal with.
>  * Worse User experience as cross project issues aren't being addressed.
>  * Previously incubated projects such as Nova, Swift, etc getting a 
> disproportionate say in things as they have a greater current user base, and 
> its increasingly hard now for new projects to gain any traction.
>  * Much less community pressure on projects to work together to elevate 
> everyone. Architectural decisions are now made at individual project level 
> with little done at the OpenStack level.
>  * etc...
>
> The overall goal of the Big Tent was to make the community more inclusive. 
> That I think has mostly happened. Which is good. But It also seems to have 
> fractured the community more into insular islands and made the system harder 
> for our operators/users. Which is bad.
>
> Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its 
> probably time to consider if it has been a net positive and should be further 
> refined to try and address some of these problems, or a net negative and 
> different approaches be explored.
>
> Thanks,
> Kevin

Sure - having a review of a major governance change like the big-tent
is a good idea, and pretty good practice.

I personally don't think we have reached the end of the transition yet,
and proposals like mine will start to come along and deal with issues
outlined above. We should be sure that we have gone as far as we can
before we claim defeat.

That said, there is serious issues - with cross project fairness being
one of the big ones (from my perspective anyway). I think getting
concrete examples of problems and tackling them is a good road forward.

- Graham

> 
> From: Hayes, Graham [graham.ha...@hpe.com]
> Sent: Thursday, July 14, 2016 12:21 PM
> To: OpenStack Development Mailing List (not for usage questions); 
> openstack...@lists.openstack.org
> Subject: [openstack-dev] [tc][all] Plugins for all
>
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross
> project interaction, or allow all projects access to the same internal
> APIs and I wanted to give a bit of background on my motivation, and how
> it came about.
>
> Coming from a smaller project, I can see issues for new projects,
> smaller projects, and projects that may not be seen as "important".
>
> As a smaller project trying to fit into cross project initiatives,
> (and yes, make sure our software looks at least OK in the
> Project Navigator) the process can be difficult.
>
> A lot of projects / repositories have plugin interfaces, but also
> have project integrations in tree, that do not follow the plugin
> interface. This makes it difficult to see what a plugin can, and
> should do.
>
> When we moved to the big tent, we wanted as a community to move to
> a flatter model, removing the old integrated status.
>
> Unfortunately we still have areas when some projects are more equal -
> there is a lingering set of projects who were integrated at the point
> in time that we moved, and have preferential status.
>
> A lot of the effects are hard to see, and are not insurmountable, but
> do cause projects to re-invent the wheel.
>
> For example, quotas - there is no way for a project that is not nova,
> neutron, cinder to hook into the standard CLI, or UI for setting
> quotas. They can be done as either extra commands
> (openstack dns quota set --foo bar) or as custom panels, but not
> the way other quotas get set.
>
> Tempest plugins are another example. Approximately 30 of the 36
> current plugins are using resources that are not supposed to be
> used, and are an unstable interface. Projects in tree in tempest
> are at a much better position, as any change to the internal
> API will have to be fixed before the gate merges, but other
> out of tree plugins are in a place where they can be broken at any
> point.
>
> None of this is meant to single out projects, or teams. A lot
> of the projects that are in this situation have inordinate amounts of
> work placed on them by the big-tent, and I can emphasize with why things
> are this way. The

Re: [openstack-dev] [tc][all] Plugins for all

[Andrew Laski]

On Thu, Jul 14, 2016, at 03:21 PM, Hayes, Graham wrote:
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross
> project interaction, or allow all projects access to the same internal
> APIs and I wanted to give a bit of background on my motivation, and how
> it came about.

Which internal APIs are you referring to here? Are you limiting this to
internal APIs within Tempest/Devstack that projects can use for
testing/deployment, or are you referring to things like the nova-compute
service which has an internal RPC API?

I feel like I'm missing some context when reading this email because
there are a lot of references to plugins with no clear definition, that
I can see, of what exactly you mean by that.

> 
> Coming from a smaller project, I can see issues for new projects,
> smaller projects, and projects that may not be seen as "important".
> 
> As a smaller project trying to fit into cross project initiatives,
> (and yes, make sure our software looks at least OK in the
> Project Navigator) the process can be difficult.
> 
> A lot of projects / repositories have plugin interfaces, but also
> have project integrations in tree, that do not follow the plugin
> interface. This makes it difficult to see what a plugin can, and
> should do.
> 
> When we moved to the big tent, we wanted as a community to move to
> a flatter model, removing the old integrated status.
> 
> Unfortunately we still have areas when some projects are more equal -
> there is a lingering set of projects who were integrated at the point
> in time that we moved, and have preferential status.
> 
> A lot of the effects are hard to see, and are not insurmountable, but
> do cause projects to re-invent the wheel.
> 
> For example, quotas - there is no way for a project that is not nova, 
> neutron, cinder to hook into the standard CLI, or UI for setting
> quotas. They can be done as either extra commands
> (openstack dns quota set --foo bar) or as custom panels, but not
> the way other quotas get set.

Can you provide more clarity on how "openstack dns quota set --foo bar"
differs from setting a quota on Nova/Neutron/Cinder?

> 
> Tempest plugins are another example. Approximately 30 of the 36
> current plugins are using resources that are not supposed to be
> used, and are an unstable interface. Projects in tree in tempest
> are at a much better position, as any change to the internal
> API will have to be fixed before the gate merges, but other
> out of tree plugins are in a place where they can be broken at any
> point.

Has there been an attempt to elevate these internal interfaces into
stable and publicly consumable interfaces? Was there resistance to such
an effort?

> 
> None of this is meant to single out projects, or teams. A lot
> of the projects that are in this situation have inordinate amounts of
> work placed on them by the big-tent, and I can emphasize with why things 
> are this way. These were the examples that currently stick out
> in my mind, and I think we have come to a point where we need to make
> a change as a community.
> 
> By moving to a "plugins for all" model, these issues are reduced.
> It undoubtedly will cause more, but it is closer to our goal
> of Recognizing all our community is part of OpenStack, and
> differentiate projects by tags.
> 
> This won't be a change that happens tomorrow, next week, or even next
> cycle, but think as a goal, we should start moving in this direction
> as soon as we can, and start building momentum.

Is this just a matter of nobody is doing this work, or are there claims
that some projects are special and should have access that other
projects do not?

> 
> Thanks,
> 
> Graham
> 
> 0 - https://review.openstack.org/342366
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Python 35 jobs currently broken (was Re: New Python35 Jobs coming)

[Clark Boylan]

On Fri, Jul 15, 2016, at 08:05 AM, Julien Danjou wrote:
> On Wed, Jul 06 2016, Andreas Jaeger wrote:
> 
> > New images for Xenial have been build and have been uploaded, first
> > tests are passing. You should now be able to check python35 jobs for
> > anything that's starting now.
> 
> Do we need to do anything to move the job to voting, or will this happen
> automagically?

You'll need to propose a change that removes the '-nv' from your
project(s) configuration when you are ready to make python3.5 jobs
voting. An example change can be found at
https://review.openstack.org/#/c/341254/

Clark

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

Re: [openstack-dev] [kolla] our mascot - input needed

[Swapnil Kulkarni (coolsvap)]

On Fri, Jul 15, 2016 at 1:38 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> The OpenStack foundation is putting together mascots for every project with
> a proper artist doing the work.  The cool thing about this is we a) get
> stickers b) have consistent look and feel among mascots in OpenStack.
>
> The downside is we have to make a decision.  The foundation wants 3-5
> choices.
>
> The mascot must be an animal and it can't involve glue or other inc007
> inspired ideas :)
>
> Obviously Koala bear is probably everyone's first choice since we have sort
> of been using that as a mascot since day one.  Anyone else have anything
> else for me to provide the foundation with a choices 2-5?
>
> Please respond quickly, the foundation needs the information shortly.  I'd
> like to offer up two alternatives just in case.
>
> Regards
> -steve
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Koala bear

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

Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Neil Jerram]

I've put my name against networking-calico, but I believe it's a no-op for
me at this stage of the tenant->project transition.  The occurrences of
'tenant' in networking-calico's code are:

./networking_calico/plugins/calico/plugin.py:45:LOG.info("Forcing
ML2 tenant_network_types to 'local'")
./networking_calico/plugins/calico/plugin.py:46:
cfg.CONF.set_override('tenant_network_types', ['local'], group='ml2')
./networking_calico/agent/dhcp_agent.py:213:  'tenant_id': ? }
./networking_calico/agent/dhcp_agent.py:298:
"tenant_id": "calico",

So it's just:
- the ML2 'tenant_network_types' config setting name
- the 'tenant_id' key used in neutron.agent.linux.dhcp.NetModel.

I guess those will be transitioned in due course.  Am I right in thinking
that there's no action for networking-calico right now, or do you think
I've missed something?

Thanks,
 Neil


On Thu, Jul 14, 2016 at 9:32 PM Henry Gessau  wrote:

> Henry Gessau  wrote:
> > In accordance with the Blueprint [1] and the spec [2], we are in the
> process
> > of deprecating the use of the term 'tenant' in favor of 'project'.
> >
> > The code change [3] with the biggest impact on Neutron developers is
> currently
> > out for review and will merge quite soon (shortly after N-2). This change
> > renames all 'tenant_id' columns in the database to 'project_id'.
> >
> > If you have any changes in flight that touch a tenant_id field, you will
> be
> > affected. Please familiarize yourself with [3], rebase on it, and comply
> with
> > the changes.
> >
> > One patch known to be affected is [4].
> >
> > The column rename change has been designed to have minimal impact on the
> usage
> > of 'tenant_id' fields. For now 'tenant_id' is still available as a
> > key/property in resource dicts and objects, and as an attribute in
> request
> > contexts.
> >
> > In the long run (Ocata or beyond) we want to end up with no usages of
> the term
> > 'tenant', except in the API for backwards compatibility. Existing usages
> of
> > 'tenant' in the codebase will be converted to 'project' on a case-by-case
> > basis. Although the conversion has not yet commenced, any *new* fields,
> > arguments, variables, etc. with 'tenant' in the name will no longer be
> accepted.
> >
> > [1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3
> > [2]
> >
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
> > [3] https://review.openstack.org/335786
> > [4] https://review.openstack.org/244680
>
> This work also affects repos that integrate with neutron and have tables in
> the Neutron database. We have started to submit patches for the
> neutron-fwaas,
> -lbaas, and -vpnaas repos, and we are keeping track of the progress with an
> etherpad [5].
>
> I have listed all the Neutron Stadium projects there, as well as all the
> projects that I could find hosted on git.openstack.org that integrate
> with the
> Neutron DB. Please help by signing up for a project.
>
> If you encounter any problem or issues, please ask us for help. Either
> reply
> to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron
> IRC
> channel.
>
> [5] https://etherpad.openstack.org/p/neutron-stadium-tenant2project
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 15/07/2016 17:10, Andrew Laski wrote:
>
>
> On Thu, Jul 14, 2016, at 03:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>
> Which internal APIs are you referring to here? Are you limiting this to
> internal APIs within Tempest/Devstack that projects can use for
> testing/deployment, or are you referring to things like the nova-compute
> service which has an internal RPC API?

Any APIs that are used by other projects. So, an RPC API will probably
be out of scope.

> I feel like I'm missing some context when reading this email because
> there are a lot of references to plugins with no clear definition, that
> I can see, of what exactly you mean by that.

It is for any project that has cross project code. If a project has
ways for other projects to hook in, this interface should be the same.

This means that a project cannot say the Nova can have code that calls
internal code but Glance has to use a plugin that only has access to
certain calls.

>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>
> Can you provide more clarity on how "openstack dns quota set --foo bar"
> differs from setting a quota on Nova/Neutron/Cinder?

Sure - nearly all other quotas are set either in the "admin" -> "quotas" 
panel in Horizon (which plugins cannot add their quotas
there.

For the cli - quotas are set as `openstack quota set --instances 10`

I realise it is a small difference, but each of these makes it more
complex for end users, and means that Designate had to re-invent the
quotas command, and keep it in their plugin.

>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> Has there been an attempt to elevate these internal interfaces into
> stable and publicly consumable interfaces? Was there resistance to such
> an effort?

When we have asked previously, we have been told that certain parts
of tempest "are not really meant for plugins".

The main part that is used that is not part of the tempest stable
interface is the base test class.

This is the bit that sets up credentials, clients, and other useful
things.

There is a base test class in the tempest lib - but it is very sparse -
meaning any project using it would have to re-invent creating users,
resources, and clients.

https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
vs
https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22

>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>> It undoubtedly will cause more, but it is closer to our goal
>> of Recognizing all our community is part of OpenStack, and
>> differentiate projects by tags.
>>
>> This won't be a change that happens tomorrow, next week, or even next
>> cycle, but think as a goal, we should start moving

Re: [openstack-dev] [tc][all] Plugins for all

[Luigi Toscano]

On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
> On 15/07/2016 17:10, Andrew Laski wrote:

> >> Tempest plugins are another example. Approximately 30 of the 36
> >> current plugins are using resources that are not supposed to be
> >> used, and are an unstable interface. Projects in tree in tempest
> >> are at a much better position, as any change to the internal
> >> API will have to be fixed before the gate merges, but other
> >> out of tree plugins are in a place where they can be broken at any
> >> point.
> > 
> > Has there been an attempt to elevate these internal interfaces into
> > stable and publicly consumable interfaces? Was there resistance to such
> > an effort?
> 
> When we have asked previously, we have been told that certain parts
> of tempest "are not really meant for plugins".
> 
> The main part that is used that is not part of the tempest stable
> interface is the base test class.
> 
> This is the bit that sets up credentials, clients, and other useful
> things.
> 
> There is a base test class in the tempest lib - but it is very sparse -
> meaning any project using it would have to re-invent creating users,
> resources, and clients.
> 
> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
> vs
> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22


This is a known situation, but it is being addressed right now. It's not like 
no one wants to have a stable Tempest interface, but it had to be cleanly 
built.
There is a spec and work in progress to make the client manager interface 
stable:

http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html

So yes, almost existing plugins are using unstable interfaces right now, but 
again this is not meant to be the long term scenario.

Ciao
-- 
Luigi

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 15/07/2016 17:52, Luigi Toscano wrote:
> On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
>> On 15/07/2016 17:10, Andrew Laski wrote:
>
 Tempest plugins are another example. Approximately 30 of the 36
 current plugins are using resources that are not supposed to be
 used, and are an unstable interface. Projects in tree in tempest
 are at a much better position, as any change to the internal
 API will have to be fixed before the gate merges, but other
 out of tree plugins are in a place where they can be broken at any
 point.
>>>
>>> Has there been an attempt to elevate these internal interfaces into
>>> stable and publicly consumable interfaces? Was there resistance to such
>>> an effort?
>>
>> When we have asked previously, we have been told that certain parts
>> of tempest "are not really meant for plugins".
>>
>> The main part that is used that is not part of the tempest stable
>> interface is the base test class.
>>
>> This is the bit that sets up credentials, clients, and other useful
>> things.
>>
>> There is a base test class in the tempest lib - but it is very sparse -
>> meaning any project using it would have to re-invent creating users,
>> resources, and clients.
>>
>> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
>> vs
>> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
>
>
> This is a known situation, but it is being addressed right now. It's not like
> no one wants to have a stable Tempest interface, but it had to be cleanly
> built.
> There is a spec and work in progress to make the client manager interface
> stable:
>
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
>
> So yes, almost existing plugins are using unstable interfaces right now, but
> again this is not meant to be the long term scenario.
>
> Ciao
>

Yeap - I have seen the spec.

My point is that if all projects had to use the same plugin interface,
this would not be a problem.

If we have this as our default position as the community continues to
build more and more things like tempest, OSC, devstack, grenade we
should build it so there is not a discrepancy between projects.

The root cause is not being addressed, as features can still land in
tempest, but not tempest.lib, and then can only be used by the projects
that tempest keeps as built in.

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

Re: [openstack-dev] [tc][all] Plugins for all

[Luigi Toscano]

On Friday, 15 July 2016 17:05:41 CEST Hayes, Graham wrote:
> On 15/07/2016 17:52, Luigi Toscano wrote:
> > On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
> >> On 15/07/2016 17:10, Andrew Laski wrote:
>  Tempest plugins are another example. Approximately 30 of the 36
>  current plugins are using resources that are not supposed to be
>  used, and are an unstable interface. Projects in tree in tempest
>  are at a much better position, as any change to the internal
>  API will have to be fixed before the gate merges, but other
>  out of tree plugins are in a place where they can be broken at any
>  point.
> >>> 
> >>> Has there been an attempt to elevate these internal interfaces into
> >>> stable and publicly consumable interfaces? Was there resistance to such
> >>> an effort?
> >> 
> >> When we have asked previously, we have been told that certain parts
> >> of tempest "are not really meant for plugins".
> >> 
> >> The main part that is used that is not part of the tempest stable
> >> interface is the base test class.
> >> 
> >> This is the bit that sets up credentials, clients, and other useful
> >> things.
> >> 
> >> There is a base test class in the tempest lib - but it is very sparse -
> >> meaning any project using it would have to re-invent creating users,
> >> resources, and clients.
> >> 
> >> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
> >> vs
> >> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
> > 
> > This is a known situation, but it is being addressed right now. It's not
> > like no one wants to have a stable Tempest interface, but it had to be
> > cleanly built.
> > There is a spec and work in progress to make the client manager interface
> > stable:
> > 
> > http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager
> > -refactor.html
> > 
> > So yes, almost existing plugins are using unstable interfaces right now,
> > but again this is not meant to be the long term scenario.
> > 
> > Ciao
> 
> Yeap - I have seen the spec.
> 
> My point is that if all projects had to use the same plugin interface,
> this would not be a problem.

Could you please clarify: do you advocate for a generic plugin interface for 
every project, or that each project should expose a plugin interface that 
allows plugin to behave as in-tree components? Because the latter is what 
happens with Tempest, and I see the former a bit complicated.

> 
> If we have this as our default position as the community continues to
> build more and more things like tempest, OSC, devstack, grenade we
> should build it so there is not a discrepancy between projects.
> 
> The root cause is not being addressed, as features can still land in
> tempest, but not tempest.lib, and then can only be used by the projects
> that tempest keeps as built in.


I think I disagree here. The root cause is being addressed: external tests can 
use the Tempest plugin interface, and use the API, which is being stabilized. 
The fact that the Tempest API is partially unstable is a temporary things, due 
to the origin of the project and the way the scope was redefined, but again 
it's temporary.

-- 
Luigi

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 15/07/2016 18:24, Luigi Toscano wrote:
> On Friday, 15 July 2016 17:05:41 CEST Hayes, Graham wrote:
>> On 15/07/2016 17:52, Luigi Toscano wrote:
>>> On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
 On 15/07/2016 17:10, Andrew Laski wrote:
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> Has there been an attempt to elevate these internal interfaces into
> stable and publicly consumable interfaces? Was there resistance to such
> an effort?

 When we have asked previously, we have been told that certain parts
 of tempest "are not really meant for plugins".

 The main part that is used that is not part of the tempest stable
 interface is the base test class.

 This is the bit that sets up credentials, clients, and other useful
 things.

 There is a base test class in the tempest lib - but it is very sparse -
 meaning any project using it would have to re-invent creating users,
 resources, and clients.

 https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
 vs
 https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
>>>
>>> This is a known situation, but it is being addressed right now. It's not
>>> like no one wants to have a stable Tempest interface, but it had to be
>>> cleanly built.
>>> There is a spec and work in progress to make the client manager interface
>>> stable:
>>>
>>> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager
>>> -refactor.html
>>>
>>> So yes, almost existing plugins are using unstable interfaces right now,
>>> but again this is not meant to be the long term scenario.
>>>
>>> Ciao
>>
>> Yeap - I have seen the spec.
>>
>> My point is that if all projects had to use the same plugin interface,
>> this would not be a problem.
>
> Could you please clarify: do you advocate for a generic plugin interface for
> every project, or that each project should expose a plugin interface that
> allows plugin to behave as in-tree components? Because the latter is what
> happens with Tempest, and I see the former a bit complicated.

For every project that has cross project interaction - tempest is a good 
example.

For these projects, they should allow all projects in tree (like Nova, 
Neutron, Cinder etc are today), or they should have a plugin interface 
(like they currently do), but all projects *must* use it, and not use
parts of tempest that are not exposed in that interface.

This would mean that tempest would move the nova, neutron, etc tests to
use the plugin interface.

Now, that plugin could be kept in the tempest repo, and still maintained
by the QA team, but should use the same interface as the other plugins
that are not in that repository.

The point is that we were supposed to be a level field as a community
but if we have examples like this, there is not a level playing field.

>>
>> If we have this as our default position as the community continues to
>> build more and more things like tempest, OSC, devstack, grenade we
>> should build it so there is not a discrepancy between projects.
>>
>> The root cause is not being addressed, as features can still land in
>> tempest, but not tempest.lib, and then can only be used by the projects
>> that tempest keeps as built in.
>
>
> I think I disagree here. The root cause is being addressed: external tests can
> use the Tempest plugin interface, and use the API, which is being stabilized.
> The fact that the Tempest API is partially unstable is a temporary things, due
> to the origin of the project and the way the scope was redefined, but again
> it's temporary.
>

But the situation could very easily re-occur. If there is a new feature
that is added to tempest, but not tempest.lib plugins will have a choice
of re implementing it, or relying on an unstable interface.


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

Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Darek Śmigiel]

> On Jul 15, 2016, at 11:33 AM, Neil Jerram  wrote:
> 
> I've put my name against networking-calico, but I believe it's a no-op for me 
> at this stage of the tenant->project transition.  The occurrences of 'tenant' 
> in networking-calico's code are:
> 
> ./networking_calico/plugins/calico/plugin.py:45:LOG.info("Forcing ML2 
> tenant_network_types to 'local'")
> ./networking_calico/plugins/calico/plugin.py:46:
> cfg.CONF.set_override('tenant_network_types', ['local'], group='ml2')
> ./networking_calico/agent/dhcp_agent.py:213:  'tenant_id': ? }
> ./networking_calico/agent/dhcp_agent.py:298:  
> "tenant_id": "calico",
> 
> So it's just:
> - the ML2 'tenant_network_types' config setting name
> - the 'tenant_id' key used in neutron.agent.linux.dhcp.NetModel.
> 
> I guess those will be transitioned in due course.  Am I right in thinking 
> that there's no action for networking-calico right now, or do you think I've 
> missed something?
> 

Hey Neil,
Thank you for adding calico.

It seems that you’re right. Probably there is no required work for 
networking-calico, but good to have all possible projects gathered in one place.
Couple of other subprojects, which do not write to Neutron DB, also are not 
changed.

Darek

> Thanks,
>  Neil
> 
> 
> On Thu, Jul 14, 2016 at 9:32 PM Henry Gessau  > wrote:
> Henry Gessau mailto:hen...@gessau.net>> wrote:
> > In accordance with the Blueprint [1] and the spec [2], we are in the process
> > of deprecating the use of the term 'tenant' in favor of 'project'.
> >
> > The code change [3] with the biggest impact on Neutron developers is 
> > currently
> > out for review and will merge quite soon (shortly after N-2). This change
> > renames all 'tenant_id' columns in the database to 'project_id'.
> >
> > If you have any changes in flight that touch a tenant_id field, you will be
> > affected. Please familiarize yourself with [3], rebase on it, and comply 
> > with
> > the changes.
> >
> > One patch known to be affected is [4].
> >
> > The column rename change has been designed to have minimal impact on the 
> > usage
> > of 'tenant_id' fields. For now 'tenant_id' is still available as a
> > key/property in resource dicts and objects, and as an attribute in request
> > contexts.
> >
> > In the long run (Ocata or beyond) we want to end up with no usages of the 
> > term
> > 'tenant', except in the API for backwards compatibility. Existing usages of
> > 'tenant' in the codebase will be converted to 'project' on a case-by-case
> > basis. Although the conversion has not yet commenced, any *new* fields,
> > arguments, variables, etc. with 'tenant' in the name will no longer be 
> > accepted.
> >
> > [1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3 
> > 
> > [2]
> > http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
> >  
> > 
> > [3] https://review.openstack.org/335786 
> > 
> > [4] https://review.openstack.org/244680 
> > 
> 
> This work also affects repos that integrate with neutron and have tables in
> the Neutron database. We have started to submit patches for the neutron-fwaas,
> -lbaas, and -vpnaas repos, and we are keeping track of the progress with an
> etherpad [5].
> 
> I have listed all the Neutron Stadium projects there, as well as all the
> projects that I could find hosted on git.openstack.org 
>  that integrate with the
> Neutron DB. Please help by signing up for a project.
> 
> If you encounter any problem or issues, please ask us for help. Either reply
> to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron IRC
> channel.
> 
> [5] https://etherpad.openstack.org/p/neutron-stadium-tenant2project 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Fox, Kevin M]

Some specific things:

Magnum trying to not use Barbican as it adds an addition dependency. See the 
discussion on the devel mailing list for details.

Horizon discussions at the summit around wanting to use Zaqar for dynamic ui 
updates instead of polling, but couldn't depend on a non widely deployed 
subsystem.

Each Advanced OpenStack Service implementing a guest controller communication 
channel that are incompatible with each other and work around communications 
issues differently. This makes a lot more pain for Ops to debug or architect a 
viable solution. For example:
 * Sahara uses ssh from the controllers to the vms. This does not play well 
with tenant networks. They have tried to work around this several ways:
* require every vm to have a floating ip. (Unnecessary attack surface)
* require the controller to be on the one and only network node (Uses ip 
netns exec to tunnel. Doesn't work for large clouds)
* Double tunnel ssh via the controller vm's. so some vms have fips, some 
don't. Better then all, but still not good.
  * Trove uses Rabbit for the guest agent to talk back to the controllers. This 
has traffic going the right direction to work well with tenant networks.
* But Rabbit is not multitenant so a security risk if any user can get into 
any one of the database vm's.
Really, I believe the right solution is to use a multitenant aware message 
queue so that the guest agent can pull in the right direction for tenant 
networks, and not have the security risk. We have such a system already, Zaqar, 
but its not widely deployed and projects don't want to depend on other projects 
that aren't widely deployed.

The lack of Instance Users has caused lots of projects to try and work around 
the lack thereof. I know for sure, Mangum, Heat, and Trove work around the 
lack. I'm positive others have too. As an operator, it makes me have to very 
carefully consider all the tradeoffs each project made, and decide if I can 
accept the same risk they assumed. Since each is different, thats much harder.

I'm sure there are more examples. but I hope you get I'm not just trying to 
troll.

The TC did apply inconsistant rules on letting projects in. That was for sure a 
negative before the big tent. But it also provided a way to apply pressure to 
projects to fix some of the issues that multiple projects face, and that plague 
user/operators and raise the whole community up, and that has fallen to the 
wayside since. Which is a big negative now. Maybe that could be bolted on top 
of the Big Tent I don't know.

I could write a very long description about the state of being an OpenStack App 
developer too that touches on all the problems with getting a consistent target 
and all the cross project communication issues there of. But thats probably for 
some other time.

Thanks,
Kevin


From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, July 15, 2016 8:17 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

Kevin, can you please be *specific* about your complaints below? Saying
things like "less project communication" and "projects not working
together because of fear of adding dependencies" and "worse user
experience" are your personal opinions. Please back those opinions up
with specific examples of what you are talking about so that we may
address specific things and not vague ideas.

Also, the overall goal of the Big Tent, as I've said repeatedly and
people keep willfully ignoring, was *not* to "make the community more
inclusive". It was to replace the inconsistently-applied-by-the-TC
*subjective* criteria for project applications to OpenStack with an
*objective* list of application requirements that could be
*consistently* reviewed by the TC.

Thanks,
-jay

On 07/14/2016 01:30 PM, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is 
> relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such 
> as:
>   * Projects not working together because of fear of adding extra 
> dependencies Ops don't already have
>   * Reimplementing features, badly, over and over again in different projects 
> instead of standardizing something.
>   * More projects being created due to politics and not technical reasons.
>   * Less cross project communication
>   * Greater Operator pain at trying to assemble a more loose confederation of 
> projects into something useful.
>   * General pushing off more and more work to Operators/Users to deal with.
>   * Worse User experience as cross project issues aren't being addressed.
>   * Previously incubated projects such as Nova, Swift, etc getting a 
> disproportionate say in things as they have a greater current user base, and 
> its increasingly hard now for new projects to gain any tr

Re: [openstack-dev] [openstack-ansible] Project Mascot

[Steve Lewis]

I am happy to support the Cape Buffalo mascot.


On Fri, Jul 15, 2016 at 8:03 AM, Truman, Travis 
wrote:

> I like the bull, cape buffalo and oxen ideas. Any would work well for us.
>
> From: Matt Thompson 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Friday, July 15, 2016 at 9:49 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack-ansible] Project Mascot
>
> Hi Jesse,
>
> I like the idea of a water buffalo, as they're working animals used in
> farming etc.  This links nicely to the project as these animals 'do the
> heavy lifting', so to speak.  An ox, etc. could be another appropriate
> mascot.
>
> --Matt
>
>
> On Fri, Jul 15, 2016 at 2:15 PM, Jesse Pretorius <
> jesse.pretor...@rackspace.co.uk> wrote:
>
>> Hi everyone,
>>
>> As discussed in the community meeting yesterday [1] the foundation wishes
>> each project to select a mascot for the project [2][3]. The mascot needs to
>> be appropriate (please read the links for the constraints) and in some way
>> linked to the project. We need to come up with a list of 3-5 options.
>>
>> Options discussed and agreed as appropriate in the meeting yesterday:
>>
>>1. A Bull (links directly to Ansible’s mascot, although ours can be
>>different).
>>2. A Cape Buffalo (distinctive, and reasonably close to a Bull).
>>
>> Please consider and reply with more options, explaining the link to the
>> project so that we can all discuss the options at the next meeting to
>> finalise our list.
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-07-14-15.58.log.html
>> [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
>> [3] http://www.openstack.org/project-mascots
>>
>> Thanks,
>>
>> Jesse
>> IRC: odyssey4me
>>
>>
>> 
>>
>> --
>> Rackspace Limited is a company registered in England & Wales (company
>> registered number 03897010) whose registered office is at 5 Millington
>> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
>> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
>> message may contain confidential or privileged information intended for the
>> recipient. Any dissemination, distribution or copying of the enclosed
>> material is prohibited. If you receive this transmission in error, please
>> notify us immediately by e-mail at ab...@rackspace.com and delete the
>> original message. Your cooperation is appreciated.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [DIB] [Ironic] [TripleO] Moving IPA element out of DIB tree

[Stephane Miller]

To better support diskimage-builder based IPA images going forward, we'd
like to move the ironic-agent element into the ironic-python-agent
repository. This will involve:

- Improving support for having multiple copies of an element, so that we
may deprecate the diskimage-builder repository copy of the element. See
this change and related: https://review.openstack.org/#/c/334785
- Moving the element into the repository. This change has been proposed as
https://review.openstack.org/#/c/335583/
- Deprecating the diskimage-builder copy of the element (TBD)
- Adding tests to gate IPA changes on DIB builds (TBD)
- Add upload of DIB-built images to tarballs.openstack.org (TBD)

Many IPA deployers currently use DIB based IPA images using the
ironic-agent element. However, IPA does not officially support DIB - IPA
changes are not tested against DIB, nor are DIB-built images published.

This has the following disadvantages:

- The DIB element is not versioned along with IPA, resulting in potential
version mismatch and breakage
- ironic-agent element changes are not tested with DIB prior to merge

Understandably, tripleo and other projects may have concerns with regard to
this change. I hope to start a discussion here so that those concerns can
be addressed. Further in-depth discussion of this issue can be found in the
relevant launchpad bug:
https://bugs.launchpad.net/ironic-python-agent/+bug/1590935

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

Re: [openstack-dev] [openstack-ansible] Project Mascot

[Ian Cordasco]

What about a forest full of . The trees in the forest can be 
all the configuration options you can specify in OSA? ;) 

-Original Message-
From: Steve Lewis 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: July 15, 2016 at 14:01:54
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [openstack-ansible] Project Mascot

> I am happy to support the Cape Buffalo mascot.
>  
>  
> On Fri, Jul 15, 2016 at 8:03 AM, Truman, Travis  
> wrote:
>  
> > I like the bull, cape buffalo and oxen ideas. Any would work well for us.
> >
> > From: Matt Thompson  
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>
> > Date: Friday, July 15, 2016 at 9:49 AM
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>
> > Subject: Re: [openstack-dev] [openstack-ansible] Project Mascot
> >
> > Hi Jesse,
> >
> > I like the idea of a water buffalo, as they're working animals used in
> > farming etc. This links nicely to the project as these animals 'do the
> > heavy lifting', so to speak. An ox, etc. could be another appropriate
> > mascot.
> >
> > --Matt
> >
> >
> > On Fri, Jul 15, 2016 at 2:15 PM, Jesse Pretorius <
> > jesse.pretor...@rackspace.co.uk> wrote:
> >
> >> Hi everyone,
> >>
> >> As discussed in the community meeting yesterday [1] the foundation wishes
> >> each project to select a mascot for the project [2][3]. The mascot needs to
> >> be appropriate (please read the links for the constraints) and in some way
> >> linked to the project. We need to come up with a list of 3-5 options.
> >>
> >> Options discussed and agreed as appropriate in the meeting yesterday:
> >>
> >> 1. A Bull (links directly to Ansible’s mascot, although ours can be
> >> different).
> >> 2. A Cape Buffalo (distinctive, and reasonably close to a Bull).
> >>
> >> Please consider and reply with more options, explaining the link to the
> >> project so that we can all discuss the options at the next meeting to
> >> finalise our list.
> >>
> >> [1]
> >> http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-07-14-15.58.log.html
> >>   
> >> [2]
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html  
> >> [3] http://www.openstack.org/project-mascots
> >>
> >> Thanks,
> >>
> >> Jesse
> >> IRC: odyssey4me
> >>
> >>
> >>  
> >>
> >> --
> >> Rackspace Limited is a company registered in England & Wales (company
> >> registered number 03897010) whose registered office is at 5 Millington
> >> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> >> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> >> message may contain confidential or privileged information intended for the
> >> recipient. Any dissemination, distribution or copying of the enclosed
> >> material is prohibited. If you receive this transmission in error, please
> >> notify us immediately by e-mail at ab...@rackspace.com and delete the
> >> original message. Your cooperation is appreciated.
> >>
> >> __ 
> >>  
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> > __  
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe  
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>  
>  
> --
> SteveL
> __  
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe  
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  

--  
Ian Cordasco


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

[openstack-dev] [Horizon] Angular action services and initScope

[Richard Jones]

Hi folks,

Something that's been bothering me for a while is that the action services
break the encapsulation model of Angular Services - that they are
singletons, and consumable by multiple simultaneous consumers without those
consumers affecting each other through their use of the Service.

At the moment the initScope() functionality we've included in the action
services breaks that model - at a minimum it is possible for multiple
consumers to initScope() with different scopes simultaneously. This is the
reason why I've been arguing (ok, "debating" :-) for the cessation of using
scopes in this way.

I think we need to do two things reasonably soon (before patterns become
more ingrained):

1. Stop passing in $scope to initScope in all cases - the new
ActionResult-enabled pattern should hopefully replace all those
2. Remove all initScope methods altogether. The only other use of initScope
that I see is the pre-loading of data used during the execution of action
allowed() methods. We should move that preloading/caching either into the
creation of the Service object itself, or into the allowed method.

If there is a use-case of initScope that I've missed (something that needs
to be execute *after* the Service is created, not something that needs to
tie the Service to a particular consumer of the service) then please let me
know :-)


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

[openstack-dev] How to develop a new [Cinder] driver?

[Turbo Fredriksson]

I'm trying to port the/a Openstack-ZFS driver to Mitaka,
but every time I do a change, I have to restart cinder-volume,
run my test command, look through the log file, modify the driver,
and back to beginning

Is there a simpler way to do this? I'm not extremely fluent
in Python (it's been over six years since I did some serious
work in it), but just importing the module and then run
through the functions in the class don't seem to work.
--
Michael Jackson is not going to buried or cremated
but recycled into shopping bags so he can remain white,
plastic and dangerous for kids to play with.


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

Re: [openstack-dev] [DIB] [Ironic] [TripleO] Moving IPA element out of DIB tree

[Ben Nemec]

I think this probably makes sense, but some more thoughts inline.

On 07/15/2016 03:13 PM, Stephane Miller wrote:
> To better support diskimage-builder based IPA images going forward, we'd
> like to move the ironic-agent element into the ironic-python-agent
> repository. This will involve:
> 
> - Improving support for having multiple copies of an element, so that we
> may deprecate the diskimage-builder repository copy of the element. See
> this change and related: https://review.openstack.org/#/c/334785
> - Moving the element into the repository. This change has been proposed
> as https://review.openstack.org/#/c/335583/
> - Deprecating the diskimage-builder copy of the element (TBD)
> - Adding tests to gate IPA changes on DIB builds (TBD)

We could potentially add tripleo-ci to the IPA repo, which would take
care of this.  As an added bonus, it could cover both the introspection
and deployment use cases for IPA.

On the other hand, if a separate Ironic job were added to cover this,
tripleo could stop ever building new IPA images in CI except in the
promote jobs when we bump our version of IPA.  This would delay our
finding problems with IPA element changes, but realistically I'm not
sure how many of those are happening these days anyway.  I'd expect that
most changes are happening in IPA itself, which we don't currently CI.

> - Add upload of DIB-built images to tarballs.openstack.org
>  (TBD)

We would also need to resolve https://review.openstack.org/#/c/334042/

I'm not clear why, but the ironic-agent element was given special
treatment in disk-image-create (which is evil, but what's done is done)
and we'd need to figure out why and a solution that wouldn't require
referencing an out-of-tree element in diskimage-builder.

> 
> Many IPA deployers currently use DIB based IPA images using the
> ironic-agent element. However, IPA does not officially support DIB - IPA
> changes are not tested against DIB, nor are DIB-built images published.

tripleo-ci actually does publish images, but they aren't well publicized
at this point, and it only does so when we promote a repo.

> 
> This has the following disadvantages:
> 
> - The DIB element is not versioned along with IPA, resulting in
> potential version mismatch and breakage
> - ironic-agent element changes are not tested with DIB prior to merge

This isn't true today.  tripleo-ci runs against all diskimage-builder
changes and uses an IPA ramdisk.  The version mismatch is a legit
problem with the current setup, although I'm not aware of any actual
breakages that have happened (which doesn't necessarily mean they
haven't :-).

> 
> Understandably, tripleo and other projects may have concerns with regard
> to this change. I hope to start a discussion here so that those concerns
> can be addressed. Further in-depth discussion of this issue can be found
> in the relevant launchpad bug:
> https://bugs.launchpad.net/ironic-python-agent/+bug/1590935
> 
> Thanks,
> Stephane
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Vitaly Gridnev]

Hello,

"Less project communication" and "projects not working together because of
fear of adding dependencies" is not so true, I think. In my opinion, Big
Tent projects are always open for integrating with each other, and we are
doing great job for making integration points much stronger. Since you
pointed out Sahara on your messages, I'll iterate with examples success
stories of integration with other projects related to sahara.

1. Since kilo/liberty we did a great job of integrating with Heat for
deploying infrastructure for clusters, and now have fully removed all
places where we were relying on our own implementation of the engine for
deploying clusters, instances and so on (code name direct engine.)

2. Since liberty/mitaka we are integrated with Barbican for improved secret
storage solution, and now we’ve implemented that by using the castellan
library.

3. Using manila shares for datasources;

4. Around liberty/mitaka sahara produced our CLI as an OpenStack Client
plugin;

5. Now we are working on integrating with designate for dns purposes.

The general problem of projects is resources that we have in our teams and
current goals we are going to reach. For example, for sahara our current
prio is really stable image generation, on making much more stable
integration tests with really good coverage of deployment clusters, work on
preparing baremetal clusters, and securing clusters.

And finally let me clarify something regarding Zaqar for using remote
operations. Sahara and Zaqar (correct me if i'm wrong) became integrated at
almost the same time, so that means that sahara was not able to rely on
Zaqar properly. And we are still open to integrating sahara with Zaqar for
remote operations. But it's not real priority for us right now because
there are plugins which don't rely on a lot of ssh operations (like Ambari
or Cloudera: these plugins are almost entirely relying on interacting with
managers via APIs), and a requirement of having a few floating ips is not
so strict even for huge deployments.


On Fri, Jul 15, 2016 at 9:36 PM, Fox, Kevin M  wrote:

> Some specific things:
>
> Magnum trying to not use Barbican as it adds an addition dependency. See
> the discussion on the devel mailing list for details.
>
> Horizon discussions at the summit around wanting to use Zaqar for dynamic
> ui updates instead of polling, but couldn't depend on a non widely deployed
> subsystem.
>
> Each Advanced OpenStack Service implementing a guest controller
> communication channel that are incompatible with each other and work around
> communications issues differently. This makes a lot more pain for Ops to
> debug or architect a viable solution. For example:
>  * Sahara uses ssh from the controllers to the vms. This does not play
> well with tenant networks. They have tried to work around this several ways:
> * require every vm to have a floating ip. (Unnecessary attack surface)
> * require the controller to be on the one and only network node (Uses
> ip netns exec to tunnel. Doesn't work for large clouds)
> * Double tunnel ssh via the controller vm's. so some vms have fips,
> some don't. Better then all, but still not good.
>   * Trove uses Rabbit for the guest agent to talk back to the controllers.
> This has traffic going the right direction to work well with tenant
> networks.
> * But Rabbit is not multitenant so a security risk if any user can get
> into any one of the database vm's.
> Really, I believe the right solution is to use a multitenant aware message
> queue so that the guest agent can pull in the right direction for tenant
> networks, and not have the security risk. We have such a system already,
> Zaqar, but its not widely deployed and projects don't want to depend on
> other projects that aren't widely deployed.
>
> The lack of Instance Users has caused lots of projects to try and work
> around the lack thereof. I know for sure, Mangum, Heat, and Trove work
> around the lack. I'm positive others have too. As an operator, it makes me
> have to very carefully consider all the tradeoffs each project made, and
> decide if I can accept the same risk they assumed. Since each is different,
> thats much harder.
>
> I'm sure there are more examples. but I hope you get I'm not just trying
> to troll.
>
> The TC did apply inconsistant rules on letting projects in. That was for
> sure a negative before the big tent. But it also provided a way to apply
> pressure to projects to fix some of the issues that multiple projects face,
> and that plague user/operators and raise the whole community up, and that
> has fallen to the wayside since. Which is a big negative now. Maybe that
> could be bolted on top of the Big Tent I don't know.
>
> I could write a very long description about the state of being an
> OpenStack App developer too that touches on all the problems with getting a
> consistent target and all the cross project communication issues there of.
> But thats probably for some other time.
>
> T

Re: [openstack-dev] How to develop a new [Cinder] driver?

[Turbo Fredriksson]

On Jul 15, 2016, at 9:33 PM, Turbo Fredriksson wrote:

> Is there a simpler way to do this?


A followup question on that: I'm using a remote SAN
and I've gotten the creation/deletion/iSCSI share/unshare
on that to work just fine.

However, when creating a volume from an image, the driver
fails on copying the image to the volume. Which is kind'a
obvious I guess, it's not (yet?) available on localhost..

I was thinking about login to the target, copy the
image onto the device that's created.

But that just don't seem to be a very .. "nice" way to
do it.. Is there a better one?
-- 
Med ett schysst järnrör slår man hela världen med häpnad
- Sockerconny


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

[openstack-dev] [api] testing openstackdocstheme and os-api-ref for API reference info

[Anne Gentle]

Hi -dev and -doc lists, and awesome devs Karen and Graham specifically -

I want to figure out the best way to coordinate a release of both the
theme and the sphinx extension so that we can test and publish and
iterate on the new API reference information display and navigation.

I think these patches are relevant and need to be merged:

openstackdocstheme
https://review.openstack.org/326668 (Actually include custom JS files)
https://review.openstack.org/329508 (API References dropdown menu)

os-api-ref
https://review.openstack.org/324805 (Tests for invalid parameter files)
https://review.openstack.org/327309 (microversion selector - dropdown)
https://review.openstack.org/318281 (HTTP Response Code Table)
https://review.openstack.org/#/c/322430/ (openstackdocstheme integration)

I think these patches are irrelevant or will keep us from the priority
task at hand, and it would be best not to merge them until we have
merged and then test these after getting the above patches released:
openstackdocstheme
https://review.openstack.org/269297 (Remove duplicate search field
from left sidebar)
https://review.openstack.org/339747 (Removed more reliance on CDNs)
https://review.openstack.org/333573 (Removed minimized files)
https://review.openstack.org/339314 (Fix the incorrect CSS values,
does something to headings I want more testing on)

I'm asking about timing and next steps. Are these the basic steps, and
am I missing any?

1. Review and merge the relevant patches in both os-api-ref and
openstackdocstheme.
2. Release new versions of  os-api-ref and openstackdocstheme.
3. Publish test content with the new versions.
4. Update relevant tox.ini and requirements.txt files.
5. Rebuild all api-ref source to implement the new navigation.

What I need to know:
Is there an order we should follow in merging so that testing across
browsers makes sense?

What is the scope of testing: is testing with the Compute content
enough or should we also test with Identity and other projects?

What timing should we attempt for steps 1 and 2 above? I'd like to aim
for August for 1 and 2, is that do-able?

Do we need to wait for all the migrated content to be ready for steps
4 and 5 above? I think the answer is no, but I might be missing
relevant info about how the navigation will work. I can also set up a
meeting for next week if that's easier than email, let me know.

Thanks,
Anne

-- 
Anne Gentle
www.justwriteclick.com

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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Elise Gafford]

Hi all,

I agree with Vitaly that Sahara's actually tried very hard to be a good
OpenStack citizen in re: integration with other Big Tent components (Heat,
Barbican, Manila, Designate...) Frequently Saharans have decided to write
such integrations in large part because it's the right thing to do for
OpenStack as an ecosystem.

At the same time, I agree with the the concerns voiced on the thread:
Sahara, like other components, has shied away from making any of the above
integrations hard dependencies; they're always strategies. Especially for
core needs like controller-to-tenant messaging, if we were to integrate
Zaqar, in order to remain perfectly stable we'd need to double our test
matrix (as it simply must work and stacks may or may not validly run Zaqar
at this point.) Big tent services (including Sahara, Trove, and others
mentioned above) do seem to me to be trying very hard to avoid becoming
leaves of the dependency graph, which is a real pity for stability and
reuse across the stack. It's absolutely true that Zaqar integration (which
would be great!) requires a lot more activation energy in the Big Tent
model than it would in the Monolithic Stack model.

I've thought about the compete-or-collaborate dynamics here a lot, though,
and in the end I don't know that there's a better governance model than
what we have. "One defcore, One OpenStack" just won't cut it eventually
(and didn't.) Organic innovation and harmful competition seem to be a bit
joined at the hip, in OpenStack and in general (I wish it weren't so daily,
but). I think the Sahara team is doing the best we can to integrate other
services as soft dependencies, as time and CI labs allow, and hope to
deprecate the pre-integration single-task stuff as we all mature together.
I suspect other teams are doing the same, and see evidence to that effect
from time to time.

I'll admit that "dependencies and collaboration are hard, and people seem
to be doing their best within that" isn't a particularly exciting stance,
but it does seem to be very true to life. :)

Cheers,
Elise Gafford
OpenStack Sahara
Senior Software Engineer, Red Hat

On Fri, Jul 15, 2016 at 5:23 PM, Vitaly Gridnev 
wrote:

> Hello,
>
> "Less project communication" and "projects not working together because of
> fear of adding dependencies" is not so true, I think. In my opinion, Big
> Tent projects are always open for integrating with each other, and we are
> doing great job for making integration points much stronger. Since you
> pointed out Sahara on your messages, I'll iterate with examples success
> stories of integration with other projects related to sahara.
>
> 1. Since kilo/liberty we did a great job of integrating with Heat for
> deploying infrastructure for clusters, and now have fully removed all
> places where we were relying on our own implementation of the engine for
> deploying clusters, instances and so on (code name direct engine.)
>
> 2. Since liberty/mitaka we are integrated with Barbican for improved
> secret storage solution, and now we’ve implemented that by using the
> castellan library.
>
> 3. Using manila shares for datasources;
>
> 4. Around liberty/mitaka sahara produced our CLI as an OpenStack Client
> plugin;
>
> 5. Now we are working on integrating with designate for dns purposes.
>
> The general problem of projects is resources that we have in our teams and
> current goals we are going to reach. For example, for sahara our current
> prio is really stable image generation, on making much more stable
> integration tests with really good coverage of deployment clusters, work on
> preparing baremetal clusters, and securing clusters.
>
> And finally let me clarify something regarding Zaqar for using remote
> operations. Sahara and Zaqar (correct me if i'm wrong) became integrated at
> almost the same time, so that means that sahara was not able to rely on
> Zaqar properly. And we are still open to integrating sahara with Zaqar for
> remote operations. But it's not real priority for us right now because
> there are plugins which don't rely on a lot of ssh operations (like Ambari
> or Cloudera: these plugins are almost entirely relying on interacting with
> managers via APIs), and a requirement of having a few floating ips is not
> so strict even for huge deployments.
>
>
> On Fri, Jul 15, 2016 at 9:36 PM, Fox, Kevin M  wrote:
>
>> Some specific things:
>>
>> Magnum trying to not use Barbican as it adds an addition dependency. See
>> the discussion on the devel mailing list for details.
>>
>> Horizon discussions at the summit around wanting to use Zaqar for dynamic
>> ui updates instead of polling, but couldn't depend on a non widely deployed
>> subsystem.
>>
>> Each Advanced OpenStack Service implementing a guest controller
>> communication channel that are incompatible with each other and work around
>> communications issues differently. This makes a lot more pain for Ops to
>> debug or architect a viable solution. For example:
>>  * Sahara uses ssh from t

[openstack-dev] [DIB] [TripleO] Should we have a DIB meeting?

[Stephane Miller]

There are a lot of interesting and complex changes going on with DIB at the
moment. This is a good thing, but it also means that we have more complex
decisions to make for the project. We've already taken one step to address
this in proposing a specs process (https://review.openstack.org/#/c/336109/).
However, I'm thinking we could also use some higher-bandwidth communication.

I'm proposing that we have a regular, IRC-based meeting for the project.
This could be done on its own, or as part of the TripleO meeting. I don't
think we necessarily need to do this every week, but a fortnightly chance
to get together to chat about big changes, design, etc would be great.

DIB and TripleO DIB community, what are your thoughts?

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

Re: [openstack-dev] [DIB] [Ironic] [TripleO] Moving IPA element out of DIB tree

[Gregory Haynes]

On Fri, Jul 15, 2016, at 03:46 PM, Ben Nemec wrote:
> I think this probably makes sense, but some more thoughts inline.
> 
> On 07/15/2016 03:13 PM, Stephane Miller wrote:
> > To better support diskimage-builder based IPA images going forward, we'd
> > like to move the ironic-agent element into the ironic-python-agent
> > repository. This will involve:
> > 
> > - Improving support for having multiple copies of an element, so that we
> > may deprecate the diskimage-builder repository copy of the element. See
> > this change and related: https://review.openstack.org/#/c/334785
> > - Moving the element into the repository. This change has been proposed
> > as https://review.openstack.org/#/c/335583/
> > - Deprecating the diskimage-builder copy of the element (TBD)
> > - Adding tests to gate IPA changes on DIB builds (TBD)

We now have some machinery to write per-element tests which result in an
image build and the ability to assert properties of that image. AFAIK no
downstreams of DIB have begun using it but this seems like a great
candidate.

> 
> We could potentially add tripleo-ci to the IPA repo, which would take
> care of this.  As an added bonus, it could cover both the introspection
> and deployment use cases for IPA.
> 
> On the other hand, if a separate Ironic job were added to cover this,
> tripleo could stop ever building new IPA images in CI except in the
> promote jobs when we bump our version of IPA.  This would delay our
> finding problems with IPA element changes, but realistically I'm not
> sure how many of those are happening these days anyway.  I'd expect that
> most changes are happening in IPA itself, which we don't currently CI.
> 
> > - Add upload of DIB-built images to tarballs.openstack.org
> >  (TBD)
> 
> We would also need to resolve https://review.openstack.org/#/c/334042/
> 
> I'm not clear why, but the ironic-agent element was given special
> treatment in disk-image-create (which is evil, but what's done is done)
> and we'd need to figure out why and a solution that wouldn't require
> referencing an out-of-tree element in diskimage-builder.
> 

I agree that this is something we should solve, but I don't think its a
blocker for the element moving out of tree - I think the (nasty) dib
special-casing will still apply as long as the element is named the
same?

I suspect this is a ways off, but an interesting question will be what
distros to base these images off of. AIUI the current published image is
CoreOS based which is something we haven't written an element for (yet).
I don't think there's any issues here, just a lot of options - Do we add
CoreOS support, do you publish multiple images built on various distros
we currently support?

> > 
> > Many IPA deployers currently use DIB based IPA images using the
> > ironic-agent element. However, IPA does not officially support DIB - IPA
> > changes are not tested against DIB, nor are DIB-built images published.
> 
> tripleo-ci actually does publish images, but they aren't well publicized
> at this point, and it only does so when we promote a repo.
> 
> > 
> > This has the following disadvantages:
> > 
> > - The DIB element is not versioned along with IPA, resulting in
> > potential version mismatch and breakage
> > - ironic-agent element changes are not tested with DIB prior to merge
> 
> This isn't true today.  tripleo-ci runs against all diskimage-builder
> changes and uses an IPA ramdisk.  The version mismatch is a legit
> problem with the current setup, although I'm not aware of any actual
> breakages that have happened (which doesn't necessarily mean they
> haven't :-).
> 

I think there's another aspect to this which is that by hosting IPA in
tree we are effectively saying that DIB should co-gate with IPA changes
(how else can IPA test changes to its element?). The problem with this
is that DIB installs a lot of things and there isn't much value in us
co-gating with every thing we install - it also isn't sustainable.
Really, we want IPA to gate on changes to the IPA element and for DIB to
have robust enough testing that it will reliably produce a workable OS
for the IPA install logic to run in. I think that moving the IPA element
in to the IPA tree makes a lot of sense from this standpoint.

As for breakages from not co-gating - all of the dib + ironic breakages
I remember were when we used the old ramdisk element which had a lot
more ironic specific logic in the element. Now that IPA is a thing and
isn't a bunch of bash inside of DIB the surface area for DIB to break
Ironic is actually pretty low (which is awesome).

> > 
> > Understandably, tripleo and other projects may have concerns with regard
> > to this change. I hope to start a discussion here so that those concerns
> > can be addressed. Further in-depth discussion of this issue can be found
> > in the relevant launchpad bug:
> > https://bugs.launchpad.net/ironic-python-agent/+bug/1590935
> > 
> > Thanks,
> > Stephane


Cheers,
Greg

___

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Tripp, Travis S]

If we find that there is still a need to send the scope in that can’t be 
reasonably worked around, then the action services could be changed to be a 
factory. The injected action factory should have a factory function called by 
the controller which creates an instance of the action in each controller.  
Then the init scope could be called on the instance of that action. This also 
would then allow actions to have state that is retained for the lifetime of the 
controller, while not worrying about sharing action state with other 
controllers.

-Travis
From: Richard Jones 
Reply-To: OpenStack List 
Date: Friday, July 15, 2016 at 2:28 PM
To: OpenStack List 
Subject: [openstack-dev] [Horizon] Angular action services and initScope

Hi folks,

Something that's been bothering me for a while is that the action services 
break the encapsulation model of Angular Services - that they are singletons, 
and consumable by multiple simultaneous consumers without those consumers 
affecting each other through their use of the Service.

At the moment the initScope() functionality we've included in the action 
services breaks that model - at a minimum it is possible for multiple consumers 
to initScope() with different scopes simultaneously. This is the reason why 
I've been arguing (ok, "debating" :-) for the cessation of using scopes in this 
way.

I think we need to do two things reasonably soon (before patterns become more 
ingrained):

1. Stop passing in $scope to initScope in all cases - the new 
ActionResult-enabled pattern should hopefully replace all those
2. Remove all initScope methods altogether. The only other use of initScope 
that I see is the pre-loading of data used during the execution of action 
allowed() methods. We should move that preloading/caching either into the 
creation of the Service object itself, or into the allowed method.

If there is a use-case of initScope that I've missed (something that needs to 
be execute *after* the Service is created, not something that needs to tie the 
Service to a particular consumer of the service) then please let me know :-)


 Richard

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

Re: [openstack-dev] [DIB] [TripleO] Should we have a DIB meeting?

[Gregory Haynes]

On Fri, Jul 15, 2016, at 06:20 PM, Stephane Miller wrote:
> There are a lot of interesting and complex changes going on with DIB
> at the moment. This is a good thing, but it also means that we have
> more complex decisions to make for the project. We've already taken
> one step to address this in proposing a specs process
> (https://review.openstack.org/#/c/336109/). However, I'm thinking we
> could also use some higher-bandwidth communication.
>
> I'm proposing that we have a regular, IRC-based meeting for the
> project. This could be done on its own, or as part of the TripleO
> meeting. I don't think we necessarily need to do this every week, but
> a fortnightly chance to get together to chat about big changes,
> design, etc would be great.
>
> DIB and TripleO DIB community, what are your thoughts?
>
> - Stephane
 
Thanks for sending this out. I'd like to add another cause for having a
weekly meeting:
 
I have noticed a pattern where our users don't have a great way to
communicate with us and often this results in some incorrect
assumptions about DIB as well as us not realizing some features that
could help these users. I've been trying to make a point to get in
contact with these downstreams and it's been pretty clear that just a
small amount of communication between them and some folks who are more
familiar with DIB goes a long way. Maybe this could serve as a sort of
open office hours for these downstreams to bring up potential issues /
ask questions / etc?
 
Something that might also work rather than decreasing frequency is
making the meeting smaller than the standard hour (maybe just a 30 min
max)? Obviously meeting times are never a minimum though, so we could
also just hope to regularly decide we are done early.
 
Anyhow, I think the risk here is very low and there's a few things it
could help with so IMO it's worth trying out.
 
Cheers,
Greg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [DIB] [Ironic] [TripleO] Moving IPA element out of DIB tree

[Jay Faulkner]

A few notes inline; I'm not the best technical contact for IPA+DIB integration, 
but going to add a little bit of context here so you all can well-understand 
our goals.

On Jul 15, 2016, at 4:28 PM, Gregory Haynes 
mailto:g...@greghaynes.net>> wrote:

On Fri, Jul 15, 2016, at 03:46 PM, Ben Nemec wrote:
I think this probably makes sense, but some more thoughts inline.

On 07/15/2016 03:13 PM, Stephane Miller wrote:
To better support diskimage-builder based IPA images going forward, we'd
like to move the ironic-agent element into the ironic-python-agent
repository. This will involve:

- Improving support for having multiple copies of an element, so that we
may deprecate the diskimage-builder repository copy of the element. See
this change and related: https://review.openstack.org/#/c/334785
- Moving the element into the repository. This change has been proposed
as https://review.openstack.org/#/c/335583/
- Deprecating the diskimage-builder copy of the element (TBD)
- Adding tests to gate IPA changes on DIB builds (TBD)

We now have some machinery to write per-element tests which result in an
image build and the ability to assert properties of that image. AFAIK no
downstreams of DIB have begun using it but this seems like a great
candidate.


We could potentially add tripleo-ci to the IPA repo, which would take
care of this.  As an added bonus, it could cover both the introspection
and deployment use cases for IPA.

On the other hand, if a separate Ironic job were added to cover this,
tripleo could stop ever building new IPA images in CI except in the
promote jobs when we bump our version of IPA.  This would delay our
finding problems with IPA element changes, but realistically I'm not
sure how many of those are happening these days anyway.  I'd expect that
most changes are happening in IPA itself, which we don't currently CI.

- Add upload of DIB-built images to 
tarballs.openstack.org
 (TBD)

We would also need to resolve https://review.openstack.org/#/c/334042/

I'm not clear why, but the ironic-agent element was given special
treatment in disk-image-create (which is evil, but what's done is done)
and we'd need to figure out why and a solution that wouldn't require
referencing an out-of-tree element in diskimage-builder.


I agree that this is something we should solve, but I don't think its a
blocker for the element moving out of tree - I think the (nasty) dib
special-casing will still apply as long as the element is named the
same?

I suspect this is a ways off, but an interesting question will be what
distros to base these images off of. AIUI the current published image is
CoreOS based which is something we haven't written an element for (yet).
I don't think there's any issues here, just a lot of options - Do we add
CoreOS support, do you publish multiple images built on various distros
we currently support?


Right now, IPA "officially" supports Tiny Core Linux and CoreOS images. We have 
people running DIB-built images based on ubuntu and fedora in production 
environments currently. The effort to get this work done for DIB is to get it 
gating on IPA changes and therefore "supported" as an official ramdisk.

Currently we publish IPA ramdisk images based on both TinyIPA (the name for our 
TCL image) and CoreOS. I'd imagine we'd end up having multiple supported DIB 
ramdisks, maybe one based on fedora, and one based on ubuntu/debian, since 
that's what the community has shown a liking for already.


Many IPA deployers currently use DIB based IPA images using the
ironic-agent element. However, IPA does not officially support DIB - IPA
changes are not tested against DIB, nor are DIB-built images published.

tripleo-ci actually does publish images, but they aren't well publicized
at this point, and it only does so when we promote a repo.


This has the following disadvantages:

- The DIB element is not versioned along with IPA, resulting in
potential version mismatch and breakage
- ironic-agent element changes are not tested with DIB prior to merge

This isn't true today.  tripleo-ci runs against all diskimage-builder
changes and uses an IPA ramdisk.  The version mismatch is a legit
problem with the current setup, although I'm not aware of any actual
breakages that have happened (which doesn't necessarily mean they
haven't :-).


I think there's another aspect to this which is that by hosting IPA in
tree we are effectively saying that DIB should co-gate with IPA changes
(how else can IPA test changes to its element?). The problem with this
is that DIB installs a lot of things and there isn't much value in us
co-gating with every thing we install - it also isn't sustainable.
Really, we want IPA to gate on changes to the IPA element and for DIB to
have robust enough testing that it will reliably produce a workable OS
for the IPA install logic to run in. I think that moving the IPA element
in to the IPA tree makes a lot of sense from this standpo

[openstack-dev] [ironic] [oslo] Stevedore 1.16 breaks IPA gate

[Jay Faulkner]

Hi all,

I wanted to get a little more light on this bug discovered: 
https://bugs.launchpad.net/stevedore/+bug/1603542. Jim posted a summary of it 
today in #openstack-oslo and didn't get a response, and it's currently breaking 
IPA's gate. If someone familiar with stevedore could please triage the bug and 
start moving it towards a resolution, I'd greatly appreciate it, as IPA's gate 
is broken and stuck until it is fixed.

While it's a big hammer I'd like to avoid using, but if there's no moment on 
this bug by Monday, I'll propose a global-requirements change to blacklist this 
version of stevedore until a solution is determined since IPA is completely 
blocked from merging changes.

This breakage does not impact the Ironic gate, as Ironic uses prebuilt TinyIPA 
ramdisk images, and no image has been published with the new breaking stevedore 
since these problems were caught in CI.

Thanks,
Jay Faulkner
OSIC

P.S. Kudos to ironic-inspector folks for writing a great unit test to catch 
this behavior in our CI rather than having it break users!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [DIB] [Ironic] [TripleO] Moving IPA element out of DIB tree

[Jay Faulkner]

One more note I missed in the previous email.

On Jul 15, 2016, at 1:46 PM, Ben Nemec 
mailto:openst...@nemebean.com>> wrote:

I think this probably makes sense, but some more thoughts inline.

On 07/15/2016 03:13 PM, Stephane Miller wrote:
To better support diskimage-builder based IPA images going forward, we'd
like to move the ironic-agent element into the ironic-python-agent
repository. This will involve:

- Improving support for having multiple copies of an element, so that we
may deprecate the diskimage-builder repository copy of the element. See
this change and related: https://review.openstack.org/#/c/334785
- Moving the element into the repository. This change has been proposed
as https://review.openstack.org/#/c/335583/
- Deprecating the diskimage-builder copy of the element (TBD)
- Adding tests to gate IPA changes on DIB builds (TBD)

We could potentially add tripleo-ci to the IPA repo, which would take
care of this.  As an added bonus, it could cover both the introspection
and deployment use cases for IPA.

On the other hand, if a separate Ironic job were added to cover this,
tripleo could stop ever building new IPA images in CI except in the
promote jobs when we bump our version of IPA.  This would delay our
finding problems with IPA element changes, but realistically I'm not
sure how many of those are happening these days anyway.  I'd expect that
most changes are happening in IPA itself, which we don't currently CI.


We already have a well-established pattern for testing multiple ramdisks under 
IPA, and this "workflow" already basically works for DIB, however, is extremely 
awkward in terms of co-gating changes (such as needing to add dependencies to 
utilize new IPA features). Here's a basic breakdown:

We set IRONIC_BUILD_DEPLOY_RAMDISK to true, which instructs the Ironic devstack 
plugin to build a new ramdisk instead of downloading and using a prebuilt 
ramdisk from tarballs.openstack.org. Which 
ramdisk gets built is determined by IRONIC_RAMDISK_TYPE. For DIB, we already 
have all the code for a job to run this way (in fact; it'd be interesting to go 
ahead and add a non-voting version of this job). 
https://github.com/openstack/ironic/blob/master/devstack/lib/ironic#L1185

There's no need for new approaches to how IPA does CI to test this; the desire 
to have the DIB element in-tree is simply to allow parallelism with the other 
build methods (which maintain their build and dependencies in-tree) and to 
prevent a situation where IPA changes are blocked on DIB element changes 
merging into another repo. This is the same approach used for Ironic in 
devstack (plugins-in-tree) and that is being worked on for Ironic in tempest, 
and I don't want to repeat mistakes of CI past of having us blocked on merging 
packages on another project's core team. (Regardless of how friendly or 
responsive you are :D).

Thanks,
Jay Faulkner
OSIC

- Add upload of DIB-built images to 
tarballs.openstack.org
 (TBD)

We would also need to resolve https://review.openstack.org/#/c/334042/

I'm not clear why, but the ironic-agent element was given special
treatment in disk-image-create (which is evil, but what's done is done)
and we'd need to figure out why and a solution that wouldn't require
referencing an out-of-tree element in diskimage-builder.


Many IPA deployers currently use DIB based IPA images using the
ironic-agent element. However, IPA does not officially support DIB - IPA
changes are not tested against DIB, nor are DIB-built images published.

tripleo-ci actually does publish images, but they aren't well publicized
at this point, and it only does so when we promote a repo.


This has the following disadvantages:

- The DIB element is not versioned along with IPA, resulting in
potential version mismatch and breakage
- ironic-agent element changes are not tested with DIB prior to merge

This isn't true today.  tripleo-ci runs against all diskimage-builder
changes and uses an IPA ramdisk.  The version mismatch is a legit
problem with the current setup, although I'm not aware of any actual
breakages that have happened (which doesn't necessarily mean they
haven't :-).


Understandably, tripleo and other projects may have concerns with regard
to this change. I hope to start a discussion here so that those concerns
can be addressed. Further in-depth discussion of this issue can be found
in the relevant launchpad bug:
https://bugs.launchpad.net/ironic-python-agent/+bug/1590935

Thanks,
Stephane


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



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe

[openstack-dev] [Congress] Mascot

[Tim Hinrichs]

Hi all,

As a reminder, we need to come up with a list of 2-3 mascots so the
OpenStack Foundation can choose 1 and turn it into a logo for Congress.
The mascots must come from the natural world (animals, plants, mountains,
waterfalls, etc.).  Deadline is July 27.

I'll get the thread started with the following animal suggestions, all of
which are called a 'congress' when there is a group of them.

salamander
raven
baboon

Any other suggestions?  Any preferences among those 3?  I'm not a fan of
baboon.

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

Re: [openstack-dev] [ironic] [oslo] Stevedore 1.16 breaks IPA gate

[Joshua Harlow]

I assume this is connected into:

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

Which was proposed a few weeks ago, I'd be nice to identify the causing 
review and see if we can find the authors to learn about why,


If its needed, proposing a requirements block is fine with me (until we 
can get to the root of this).


-Josh

Jay Faulkner wrote:

Hi all,

I wanted to get a little more light on this bug discovered:
https://bugs.launchpad.net/stevedore/+bug/1603542
. Jim posted a
summary of it today in #openstack-oslo and didn't get a response, and
it's currently breaking IPA's gate. If someone familiar with stevedore
could please triage the bug and start moving it towards a resolution,
I'd greatly appreciate it, as IPA's gate is broken and stuck until it is
fixed.

While it's a big hammer I'd like to avoid using, but if there's no
moment on this bug by Monday, I'll propose a global-requirements change
to blacklist this version of stevedore until a solution is determined
since IPA is completely blocked from merging changes.

This breakage does not impact the Ironic gate, as Ironic uses prebuilt
TinyIPA ramdisk images, and no image has been published with the new
breaking stevedore since these problems were caught in CI.

Thanks,
Jay Faulkner
OSIC

P.S. Kudos to ironic-inspector folks for writing a great unit test to
catch this behavior in our CI rather than having it break users!

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


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

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Alex Xu]

2016-07-14 10:38 GMT+08:00 Cheng, Yingxin :

>
> On 7/14/16, 05:42, "Ed Leafe"  wrote:
> On Jul 12, 2016, at 2:43 AM, Cheng, Yingxin 
> wrote:
> > 4. Capabilities are managed/grouped/abstracted by namespaces, and
> scheduler can make decisions based on either cap_names or cap_namespaces
> > 5. Placement service DON’T have any specific knowledge of a
> capability, it only know the its name, namespaces, its relationship to
> resource providers. They are used for scheduling, capability management and
> report.
>
> Thinking about that a bit, it would seem that a host aggregate could
> also be represented as a namespace:name tag. That makes sense, since the
> fact that a host belongs to a particular aggregate is a qualitative aspect
> of that host.
>
>
> Thanks for the feedback!
>
> We’ve thought about the relationship between capability tags and host
> aggregates carefully. And we decide not to blend it with host aggregates,
> for several reasons below:
> 1. We want to manage capabilities in only ONE place, either in host
> aggregates, compute_node records or with resource_provider records.
> 2. Compute services may need to attach discovered capabilities to its
> host. It is inconvenient if we store caps with host aggregates, because
> nova-compute needs to create/search host aggregates first, it can’t
> directly attach caps.
> 3. Other services may need to attach discovered capabilities to its
> resources. So the best place is to its related resource pool, not
> aggregates, nor compute_node records. Note the relationship between
> resource pools and host aggregates are N:N.
> 4. It’s logically correct to store caps with resource_providers, because
> caps are actually owned by nodes or resource pools.
> 5. Scheduling will be faster if resource-providers are directly attached
> with caps.
>
> However, for user-defined caps, it still seems easier to manage them with
> aggregates. We may want to manage them in a way different from pre-defined
> caps. Or we can indirectly manage them through aggregates, but they are
> actually stored with compute-node resource-providers in placement db.
>

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.


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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Hongbin Lu]

No, Magnum still uses Barbican as an optional dependency, and I believe nobody 
has proposed to remove Barbican entirely. I have no position about big tent but 
using Magnum as an example of "projects are not working together" is 
inappropriate.

Best regards,
Hongbin

> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: July-15-16 2:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> 
> Some specific things:
> 
> Magnum trying to not use Barbican as it adds an addition dependency.
> See the discussion on the devel mailing list for details.
> 
> Horizon discussions at the summit around wanting to use Zaqar for
> dynamic ui updates instead of polling, but couldn't depend on a non
> widely deployed subsystem.
> 
> Each Advanced OpenStack Service implementing a guest controller
> communication channel that are incompatible with each other and work
> around communications issues differently. This makes a lot more pain
> for Ops to debug or architect a viable solution. For example:
>  * Sahara uses ssh from the controllers to the vms. This does not play
> well with tenant networks. They have tried to work around this several
> ways:
> * require every vm to have a floating ip. (Unnecessary attack
> surface)
> * require the controller to be on the one and only network node
> (Uses ip netns exec to tunnel. Doesn't work for large clouds)
> * Double tunnel ssh via the controller vm's. so some vms have fips,
> some don't. Better then all, but still not good.
>   * Trove uses Rabbit for the guest agent to talk back to the
> controllers. This has traffic going the right direction to work well
> with tenant networks.
> * But Rabbit is not multitenant so a security risk if any user can
> get into any one of the database vm's.
> Really, I believe the right solution is to use a multitenant aware
> message queue so that the guest agent can pull in the right direction
> for tenant networks, and not have the security risk. We have such a
> system already, Zaqar, but its not widely deployed and projects don't
> want to depend on other projects that aren't widely deployed.
> 
> The lack of Instance Users has caused lots of projects to try and work
> around the lack thereof. I know for sure, Mangum, Heat, and Trove work
> around the lack. I'm positive others have too. As an operator, it makes
> me have to very carefully consider all the tradeoffs each project made,
> and decide if I can accept the same risk they assumed. Since each is
> different, thats much harder.
> 
> I'm sure there are more examples. but I hope you get I'm not just
> trying to troll.
> 
> The TC did apply inconsistant rules on letting projects in. That was
> for sure a negative before the big tent. But it also provided a way to
> apply pressure to projects to fix some of the issues that multiple
> projects face, and that plague user/operators and raise the whole
> community up, and that has fallen to the wayside since. Which is a big
> negative now. Maybe that could be bolted on top of the Big Tent I don't
> know.
> 
> I could write a very long description about the state of being an
> OpenStack App developer too that touches on all the problems with
> getting a consistent target and all the cross project communication
> issues there of. But thats probably for some other time.
> 
> Thanks,
> Kevin
> 
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Friday, July 15, 2016 8:17 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> 
> Kevin, can you please be *specific* about your complaints below? Saying
> things like "less project communication" and "projects not working
> together because of fear of adding dependencies" and "worse user
> experience" are your personal opinions. Please back those opinions up
> with specific examples of what you are talking about so that we may
> address specific things and not vague ideas.
> 
> Also, the overall goal of the Big Tent, as I've said repeatedly and
> people keep willfully ignoring, was *not* to "make the community more
> inclusive". It was to replace the inconsistently-applied-by-the-TC
> *subjective* criteria for project applications to OpenStack with an
> *objective* list of application requirements that could be
> *consistently* reviewed by the TC.
> 
> Thanks,
> -jay
> 
> On 07/14/2016 01:30 PM, Fox, Kevin M wrote:
> > I'm going to go ahead and ask the difficult question now as the
> answer is relevant to the attached proposal...
> >
> > Should we reconsider whether the big tent is the right approach going
> forward?
> >
> > There have been some major downsides I think to the Big Tent approach,
> such as:
> >   * Projects not working together because of fear of adding extra
> dependencies Ops don't already have
> >   * Reimplementing features, badl