[openstack-dev] [octavia] connection to external network

[Volodymyr Litovka]

Hello colleagues,

I think I'm missing something architectural in LBaaS / Octavia, thus 
asking there - how to connect Amphora agent to external network? My 
current lab topology is the following:


    +
    |
    |    ++
    +   ++ n1 |
    |    +-+    |    ++
    ++ Amphora ++
    |    +-+    |    ++
  m | n ++ n2 |
  g | b |    ++    + e
  m | t |  | x
  t |   |    ++    | t
    | s ++ vR ++ e
    | u |    ++    | r
   ++ b |  | n
   | Controller | n |    ++    | a
   ++ e |+ n3 |    + l
  t |    ++
    +

where "Amphora" is agent which loadbalances requests between "n1" and "n2":

 * openstack loadbalancer create --name lb1 --vip-subnet-id nbt-subnet
   --project bush
 * openstack loadbalancer listener create --protocol TCP
   --protocol-port 80 --name lis1 lb1
 * openstack loadbalancer pool create --protocol TCP --listener lis1
   --name lpool1 --lb-algorithm ROUND_ROBIN
 * openstack loadbalancer member create --protocol-port 80 --name n1
   --address 1.1.1.11 lpool1
 * openstack loadbalancer member create --protocol-port 80 --name n2
   --address 1.1.1.14 lpool1

Everything works (n3-sourced connections to Amphora-agent return answers 
from n1 and n2 respectively in round robin way) and the question is how 
to connect Amphora-agent to external network in order to service 
requests from outside?


In example above, nbt-subnet (which is VIP network) has a virtual router 
which is connected to external network and has all abilities to provide 
e.g. floating ip to Amphora, but I see nothing in octavia config files 
regarding floating ip functions.


Am I missing something? Any ways on connect Web-servers in closed 
(project's) networks with Internet using Octavia / LBaaS?


Thank you!

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

__
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] [all] Dublin PTG format

[Thierry Carrez]

Hi everyone,

We are in the final step in the process of signing the contract with the
PTG venue. We should be able to announce the location this week !

So it's time to start preparing. We'll have 5 days, like in Denver. One
thing we'd like to change for this round is to give a bit more
flexibility in the topics being discussed, especially in the first two days.

In Denver, we selected a number of general "themes" and gave them all a
room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
project team meeting could get a room for 2 or 3 days on
Wednesday-Friday. That resulted in a bit of flux during the first two
days, with a lot of empty rooms as most of the themes did not really
need 2 days, and a lot of conflicts were present.

For Dublin, the idea would be to still predetermine topics (themes and
teams) and assign them rooms in advance. But we would be able to assign
smaller amounts of time (per half-day) based on the expressed needs.
Beyond those pre-assigned themes/teams we'd add flexibility for other
groups to book the remaining available rooms in 90-min slots on-demand.
A bit like how we did reservable rooms in the past, but more integrated
with the rest of the event. It would all be driven by the PTGbot, which
would show which topic is being discussed in which room, in addition to
the current discussion subject within each topic.

We have two options in how we do the split for predetermined topics. We
used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
general idea there was to allow some people only interested in a team
meeting to only attend the second part of the week. However most people
attend all 5 days, and during event feedback some people suggested that
"themes" should be in the mornings and "teams" in the afternoons (and
all Friday).

What would be your preference ? The Mon-Tue/Wed-Fri split means less
room changes, which make it easier on the events team. So all else being
equal we'd rather keep it the way it is, but I'm open to changing it if
attendees think it's a good idea.

If you have any other suggestion (that we could implement in the 3
months we have between now and the event) please let me know :)

-- 
Thierry Carrez (ttx)

__
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] save the date: virtual midcycle on Nov 27th

[Dmitry Tantsur]

Reminder: the call is today, in a bit more than 3 hours!

This also means that we won't have a usual meeting today.

On 11/20/2017 06:11 PM, Dmitry Tantsur wrote:

On 11/20/2017 05:49 PM, Dmitry Tantsur wrote:

Hi all!

The winning date for the midcycle is Nov 27th. The call will take up to 4 
hours, 3pm UTC to 7pm UTC (unless I'm confusing time zones again). We will use 
the bluejeans room https://bluejeans.com/973312948 (works without plugins in 
recent browsers, see the etherpad for details).


Please also keep adding potential topics to 
https://etherpad.openstack.org/p/ironic-queens-midcycle


Small update: we have 4 topics for 4 hours already. We will cover additional 
topics only if time allows. Also if your topic requires any preparation, please 
propose it ASAP.




Dmitry





__
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 update week 48

[Balazs Gibizer]

Hi,

Here is the status update / focus settings mail for w48

Bugs

[Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration
of 'notify_on_state_change' are different from implementation
As the behavior is unchanged in the last 5 years a patch is proposed to
update the documentation to reflect this long standing behavior.
The fix merged to the master and backports has been proposed to the
stable branches https://review.openstack.org/#/q/topic:bug/1535254

Versioned notification transformation
-
The following transformation patches are ready:
* https://review.openstack.org/#/c/410297 Transform missing delete
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context
manager
* https://review.openstack.org/#/c/396811 Transform 
instance.resize_revert notification


Service create and destroy notifications

https://blueprints.launchpad.net/nova/+spec/service-create-destroy-notification
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/service-create-destroy-notification.html
The implementation needs a second core to look at 
https://review.openstack.org/#/c/519588/ .


Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples

Nothing is open on that branch today. I have do some of these patches 
during the week.


Weekly meeting
--
Next subteam meeting will be held on 28th of November, Tuesday 17:00
UTC on openstack-meeting-4.
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171128T17


Cheers,
gibi




__
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] upstream OVB jobs - roadmap

[Alfredo Moralejo Alonso]

On Thu, Nov 23, 2017 at 7:59 PM, Emilien Macchi  wrote:

> Queens's main theme is stabilization.
> That's what we're currently working on in our CI, see which areas we
> can consolidate and stabilize so we can continue to scale TripleO
> development.
>
> One of the challenges that we had in the last years was the high
> demand of OVB jobs versus the capacity.
> To address that, we recently decided to remove ovb-nonha. It was a good
> start.
>
> Now we have:
> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics)
> - ovb-containers which tested a containerized overcloud
> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from
> ovb-updates and is supposed to test ipv6 overcloud, stack updates &
> ceph. It doesn't test stack updates (since the switch to
> tripleo-quickstart), and Ceph is already extensively tested in
> multinode scenario001/004 jobs.
>
> That said, I think we can consolidate the OVB jobs in 2:
>
> - keep ovb-ha and containerize it in Queens and beyond: it was already
> approved and change is being applied now:
> https://review.openstack.org/#/c/522293/
>   indeed, we decided as a community that we would stop supporting
> non-containerized overclouds in Queens and beyond.
>

We still have some multinode jobs running non-containerized deployment in
periodic pipeline (failing after https://review.openstack.org/#/c/518423/).
Should we remove these jobs?


> - remove ovb-containers in Queens and beyond: useless now, since we
> have ovb-ha containerized: https://review.openstack.org/#/c/522579/
> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6:
> https://review.openstack.org/#/c/522618/
>   indeed, ceph is already well tested in scenarios, ipv6 would be
> tested in ovb-ha-ipv6.
>   for overcloud updates, I haven't seen the feature in quickstart but
> I might have missed something (any help here is welcome).
>
> At the end, we should end up with 2 OVB jobs:
> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps)
> - ovb-ha-ipv6
>
> Both would test the things that can't be tested by multinode:
> - Nova / Ironic / Mistral workflow
> - Introspection
> - TLS
> - Network Isolation
> - IPv6 for the ovb-ha-ipv6
> - Containerized overcloud
>
> As a result, we have more coverage (except for stack updates but it
> needs to be addressed in quickstart first) and less jobs, so less
> resources consumed.
>
> Any feedback on this plan is more than welcome,
> --
> 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
>
__
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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Flavio Percoco]

Greetings,

Last Thursday[0], at the TC office hours, we brainstormed a bit around the idea
of having a tech blog. This idea came first from Joshua Harlow and it was then
briefly discussed at the summit too.

The idea, we have gathered, is to have a space where the community could write
technical posts about OpenStack. The idea is not to have an aggregator (that's
what our planet[1] is for) but a place to write original and curated content.
During the conversation, we argued about what kind of content would be
acceptable for this platform. Here are some ideas of things we could have there:

- Posts that are dev-oriented (e.g: new functions on an oslo lib)
- Posts that facilitate upstream development (e.g: My awesome dev setup)
- Deep dive into libvirt internals
- ideas?

As Chris Dent pointed out on that conversation, we should avoid making this
place a replacement for things that would otherwise go on the mailing list -
activity reports, for example. Having dev news in this platform, we would
overlap with things that go already on the mailing list and, arguably, we would
be defeating the purpose of the platform. But, there might be room for both(?)

Ultimately, we should avoid topics promoting new features in services as that's 
what
superuser[2] is for.

So, what are your thoughts about this? What kind of content would you rather
have posted here? Do you like the idea at all?

[0] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-23.log.html#t2017-11-23T15:01:25
[1] http://planet.openstack.org/
[2] http://superuser.openstack.org/

Flavio

--
@flaper87
Flavio Percoco


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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Dan Prince]

On Mon, Nov 27, 2017 at 8:55 AM, Flavio Percoco  wrote:

> Greetings,
>
> Last Thursday[0], at the TC office hours, we brainstormed a bit around the
> idea
> of having a tech blog. This idea came first from Joshua Harlow and it was
> then
> briefly discussed at the summit too.
>
> The idea, we have gathered, is to have a space where the community could
> write
> technical posts about OpenStack. The idea is not to have an aggregator
> (that's
> what our planet[1] is for) but a place to write original and curated
> content.
>

Why not just write article's on existing blogs, link them into planet, and
then if they are really good promote them at a higher level?

Having a separate blog that is maintained by a few seems a bit elitist to
me.

Dan


> During the conversation, we argued about what kind of content would be
> acceptable for this platform. Here are some ideas of things we could have
> there:
>
> - Posts that are dev-oriented (e.g: new functions on an oslo lib)
> - Posts that facilitate upstream development (e.g: My awesome dev setup)
> - Deep dive into libvirt internals
>

What is really missing in our current infrastructure setup that really
prevents any of the above?


> - ideas?
>
> As Chris Dent pointed out on that conversation, we should avoid making this
> place a replacement for things that would otherwise go on the mailing list
> -
> activity reports, for example. Having dev news in this platform, we would
> overlap with things that go already on the mailing list and, arguably, we
> would
> be defeating the purpose of the platform. But, there might be room for
> both(?)
>
> Ultimately, we should avoid topics promoting new features in services as
> that's what
> superuser[2] is for.
>
> So, what are your thoughts about this? What kind of content would you
> rather
> have posted here? Do you like the idea at all?
>
> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23op
> enstack-tc.2017-11-23.log.html#t2017-11-23T15:01:25
> [1] http://planet.openstack.org/
> [2] http://superuser.openstack.org/
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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] ANNOUNCE: Self-healing SIG officially formed (fwd)

[Adam Spiers]

As per below, I'm happy to announce that the Self-healing SIG is now
officially formed.  For now, all discussions will happen on
, so please subscribe to that list
if you are interested in this topic!

Cheers,
Adam

- Forwarded message from Adam Spiers  -

Date: Mon, 27 Nov 2017 14:19:25 +
From: Adam Spiers 
To: OpenStack SIGs list 
Subject: [Openstack-sigs] [meta] [self-healing] ANNOUNCE: Self-healing SIG 
officially formed
Reply-To: openstack-s...@lists.openstack.org

TL;DR: the self-healing SIG is officially formed!  Watch the openstack-sigs 
mailing list for future developments.


A longer version of this announcement can be found at

  https://blog.adamspiers.org/2017/11/24/announcing-openstacks-self-healing-sig/


A SIG is born!
--

After an unofficial kick-off meeting at the last PTG in Denver, I proposed the 
creation of a new self-healing SIG:


  http://lists.openstack.org/pipermail/openstack-sigs/2017-September/54.html

At the recent Summit in Sydney, we had a Forum session around 30 people attend 
the Sydney Forum session, which was extremely encouraging! You can read more 
details in the etherpad, but here is the quick summary ...


Most importantly, we resolved the naming and scoping issues, concluding that 
to avoid biting off too much in one go, it was better to be pragmatic and 
start small:


- Initially focus on cloud infrastructure, and not worry too much
  about the user-facing impact of failures yet; we can add that
  concern whenever it makes sense (which is particularly relevant
  for telcos / NFV).

- Not worry too much about optimization initially; Watcher is
  possibly the only project focusing on this right now, and again we
  can expand to include optimization any time we want.

Now that the naming and scoping issues are resolved, I am excited to announce 
that the Self-healing SIG is officially formed!


Discussion went beyond mere administravia, however:

- We collected a few initial use cases.

- We informally decided the governance of the SIG. I asked if anyone
  else would like to assume leadership, but noone seemed keen,
  dashing my hopes of avoiding extra work ;-)  But Eric Kao, PTL of
  Congress, generously offered to act as co-chair.

- We discussed health check APIs, which were mentioned in at least 2
  or 3 other Forum sessions this time round.

- We agreed that we wanted an IRC channel, and that it could host
  bi-weekly meetings. However as usual there was no clean solution
  to choosing a time which would suit everyone ;-/  I'll try to
  figure out what to do about this!


Get involved


You are warmly invited to join, if this topic interests you:

- Ensure you are subscribed to the openstack-sigs mailing list:

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

  and watch out watch out for posts tagged =[self-healing]=.

- Bookmark https://wiki.openstack.org/wiki/Self-healing_SIG
  which is the SIG's official home.


Next steps
--

I will set up the IRC channel, and see if we can make progress on agreeing 
times for regular IRC meetings.


Other than this administravia, it is of course up to the community to decide 
in which direction the SIG should go, but my suggestions are:


- Continue to collect use cases.  It makes sense to have a very
  lightweight process for this (at least, initially), so Eric has
  created a Google Doc and populated it with a suggested template and
  a first example:


https://docs.google.com/document/d/13N36g2RlUYs8mw7hbfRXw6y2Jc-V2XGrXgfPXPpUvuU/edit?usp=sharing

  Feel free to add your own based on this template.

- Collect links to any existing documentation or other resources which
  describe how existing services can be combined.  This awesome talk
  on Advanced Fault Management with Vitrage and Mistral is a perfect
  example:

  
https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral

  and here is another:

  
https://www.openstack.org/videos/barcelona-2016/building-self-healing-applications-with-aodh-zaqar-and-mistral

  but we need to make it easier for operators to understand which
  combinations like this are possible, and easier for them to be set
  up.

- Finish the architecture diagram drafted in Denver:


https://docs.google.com/drawings/d/1kEFtVpQ4c8HipSp34EVAkcSGmwyg1MzWf_H5oGTtl-Y/edit?usp=sharing

- At a higher level, we could document reference stacks which address
  multiple self-healing cases.

- Talk more with the OPNFV community to find out what capabilities
  they have which could be reused within non-NFV OpenStack clouds.

- Perform gaps analysis on the use cases, and liase with specific
  projects to drive development in directions which can address those
  gaps.

___
openstack-sigs mailing list
openstack-s...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

- End forwarded message -

Re: [openstack-dev] [tripleo] upstream OVB jobs - roadmap

[Emilien Macchi]

On Mon, Nov 27, 2017 at 5:44 AM, Alfredo Moralejo Alonso
 wrote:
>
>
> On Thu, Nov 23, 2017 at 7:59 PM, Emilien Macchi  wrote:
>>
>> Queens's main theme is stabilization.
>> That's what we're currently working on in our CI, see which areas we
>> can consolidate and stabilize so we can continue to scale TripleO
>> development.
>>
>> One of the challenges that we had in the last years was the high
>> demand of OVB jobs versus the capacity.
>> To address that, we recently decided to remove ovb-nonha. It was a good
>> start.
>>
>> Now we have:
>> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics)
>> - ovb-containers which tested a containerized overcloud
>> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from
>> ovb-updates and is supposed to test ipv6 overcloud, stack updates &
>> ceph. It doesn't test stack updates (since the switch to
>> tripleo-quickstart), and Ceph is already extensively tested in
>> multinode scenario001/004 jobs.
>>
>> That said, I think we can consolidate the OVB jobs in 2:
>>
>> - keep ovb-ha and containerize it in Queens and beyond: it was already
>> approved and change is being applied now:
>> https://review.openstack.org/#/c/522293/
>>   indeed, we decided as a community that we would stop supporting
>> non-containerized overclouds in Queens and beyond.
>
>
> We still have some multinode jobs running non-containerized deployment in
> periodic pipeline (failing after https://review.openstack.org/#/c/518423/).
> Should we remove these jobs?

Yes and sorry if we missed it.

>>
>> - remove ovb-containers in Queens and beyond: useless now, since we
>> have ovb-ha containerized: https://review.openstack.org/#/c/522579/
>> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6:
>> https://review.openstack.org/#/c/522618/
>>   indeed, ceph is already well tested in scenarios, ipv6 would be
>> tested in ovb-ha-ipv6.
>>   for overcloud updates, I haven't seen the feature in quickstart but
>> I might have missed something (any help here is welcome).
>>
>> At the end, we should end up with 2 OVB jobs:
>> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps)
>> - ovb-ha-ipv6
>>
>> Both would test the things that can't be tested by multinode:
>> - Nova / Ironic / Mistral workflow
>> - Introspection
>> - TLS
>> - Network Isolation
>> - IPv6 for the ovb-ha-ipv6
>> - Containerized overcloud
>>
>> As a result, we have more coverage (except for stack updates but it
>> needs to be addressed in quickstart first) and less jobs, so less
>> resources consumed.
>>
>> Any feedback on this plan is more than welcome,
>> --
>> 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
>
>
>
> __
> 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
>



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

[openstack-dev] [infra][qa] Zuulv3 jobs fail due to an authentication issue

[Martin Kopec]

Hello,

I'm having authentication issues during running my zuulv3 playbook [1] for
python-tempestconf project even when admin credentials are sourced. It
happens so when python-tempestconf tries to send a POST request and it
happens using devstack [2] and packstack [3] environment as well.
Also I installed environments manually but I wasn't able to reproduce the
issue.

I've tried to run openstack commands (openstack user create, ...) in
ansible shell module but they haven't worked as well. However, they worked
when I used os_* modules.

My guess would be, that environment variables are not set properly, but
according to the printenv command, all required environment variables are
set correctly. Or maybe the POST request is for some reason forbidden in
the environment, ..

Due to the fact, it fails on devstack and packstack with the same error and
not all openstack commands can be run from shell, I think it could be an
environment issue. Have you seen something like that? Any guesses or ideas
why it does happen or what I should try?

Thank you very much for any help.

[1] https://review.openstack.org/#/c/513330/
[2]
http://logs.openstack.org/30/513330/54/check/python-tempestconf-tempest-devstack/c9fbb41/job-output.txt.gz#_2017-11-27_13_03_11_186300
[3]
http://logs.openstack.org/30/513330/54/check/python-tempestconf-tempest-packstack/2f71b7d/job-output.txt.gz#_2017-11-27_13_16_02_904654

Martin Kopec
__
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] Community managed tech/dev blog: Call for opinions and ideas

[Amrith Kumar]

I don't see much of a point in an OpenStack Technical blog. After all,
those who want to blog likely already have blogs that are syndicated
through the OpenStack digest mechanism.

What problem or existing shortcoming is sought to be addressed by this
blog? And is there some reason that existing (individual) blogs can't be
used for this?

The issue may be centralization and longevity which, given the transient
nature of all of our involvement in OpenStack is a perfectly legitimate
concern. But, I'd like that this be articulated clearly if it is in fact
the issue.

-amrith


On Mon, Nov 27, 2017 at 9:16 AM, Dan Prince  wrote:

>
>
> On Mon, Nov 27, 2017 at 8:55 AM, Flavio Percoco  wrote:
>
>> Greetings,
>>
>> Last Thursday[0], at the TC office hours, we brainstormed a bit around
>> the idea
>> of having a tech blog. This idea came first from Joshua Harlow and it was
>> then
>> briefly discussed at the summit too.
>>
>> The idea, we have gathered, is to have a space where the community could
>> write
>> technical posts about OpenStack. The idea is not to have an aggregator
>> (that's
>> what our planet[1] is for) but a place to write original and curated
>> content.
>>
>
> Why not just write article's on existing blogs, link them into planet, and
> then if they are really good promote them at a higher level?
>
> Having a separate blog that is maintained by a few seems a bit elitist to
> me.
>
> Dan
>
>
>> During the conversation, we argued about what kind of content would be
>> acceptable for this platform. Here are some ideas of things we could have
>> there:
>>
>> - Posts that are dev-oriented (e.g: new functions on an oslo lib)
>> - Posts that facilitate upstream development (e.g: My awesome dev setup)
>> - Deep dive into libvirt internals
>>
>
> What is really missing in our current infrastructure setup that really
> prevents any of the above?
>
>
>> - ideas?
>>
>> As Chris Dent pointed out on that conversation, we should avoid making
>> this
>> place a replacement for things that would otherwise go on the mailing
>> list -
>> activity reports, for example. Having dev news in this platform, we would
>> overlap with things that go already on the mailing list and, arguably, we
>> would
>> be defeating the purpose of the platform. But, there might be room for
>> both(?)
>>
>> Ultimately, we should avoid topics promoting new features in services as
>> that's what
>> superuser[2] is for.
>>
>> So, what are your thoughts about this? What kind of content would you
>> rather
>> have posted here? Do you like the idea at all?
>>
>> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23op
>> enstack-tc.2017-11-23.log.html#t2017-11-23T15:01:25
>> [1] http://planet.openstack.org/
>> [2] http://superuser.openstack.org/
>>
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Melvin Hillsman]

On Mon, Nov 27, 2017 at 8:16 AM, Dan Prince  wrote:

>
>
> On Mon, Nov 27, 2017 at 8:55 AM, Flavio Percoco  wrote:
>
>> Greetings,
>>
>> Last Thursday[0], at the TC office hours, we brainstormed a bit around
>> the idea
>> of having a tech blog. This idea came first from Joshua Harlow and it was
>> then
>> briefly discussed at the summit too.
>>
>> The idea, we have gathered, is to have a space where the community could
>> write
>> technical posts about OpenStack. The idea is not to have an aggregator
>> (that's
>> what our planet[1] is for) but a place to write original and curated
>> content.
>>
>
> Why not just write article's on existing blogs, link them into planet, and
> then if they are really good promote them at a higher level?
>
> Having a separate blog that is maintained by a few seems a bit elitist to
> me.
>
> Dan
>

+1


>
>> During the conversation, we argued about what kind of content would be
>> acceptable for this platform. Here are some ideas of things we could have
>> there:
>>
>> - Posts that are dev-oriented (e.g: new functions on an oslo lib)
>> - Posts that facilitate upstream development (e.g: My awesome dev setup)
>> - Deep dive into libvirt internals
>>
>
> What is really missing in our current infrastructure setup that really
> prevents any of the above?
>

+1


>
>
>> - ideas?
>>
>> As Chris Dent pointed out on that conversation, we should avoid making
>> this
>> place a replacement for things that would otherwise go on the mailing
>> list -
>> activity reports, for example. Having dev news in this platform, we would
>> overlap with things that go already on the mailing list and, arguably, we
>> would
>> be defeating the purpose of the platform. But, there might be room for
>> both(?)
>>
>> Ultimately, we should avoid topics promoting new features in services as
>> that's what
>> superuser[2] is for.
>>
>> So, what are your thoughts about this? What kind of content would you
>> rather
>> have posted here? Do you like the idea at all?
>>
>> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23op
>> enstack-tc.2017-11-23.log.html#t2017-11-23T15:01:25
>> [1] http://planet.openstack.org/
>> [2] http://superuser.openstack.org/
>>
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>

My .02, I would like to encourage in general we try to streamline and make
more effective what we already do versus adding more and remove excess.


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
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][placement] Review push this week

[Eric Fried]

Nova devs (especially cores):

In this week's scheduler meeting [1] we fondly recalled our vigorous
agreement at the PTG to merge the big stuff early in the cycle. We
lamented the extent to which Sydney + Thanksgiving drained our review
resources for much of November, and shed a tear in anticipation of the
dreaded Holiday Season having a similar effect in December. As such, we
resolved to request a deliberate and focussed effort to review and merge
outstanding patches associated with the three major Queens priorities
[2] this week. For your convenience, here is a handy list of said
patches/series:

=> Nested Resource Providers. Series starting at:
https://review.openstack.org/#/c/377138/

=> Alternate Hosts. Series starting at:
https://review.openstack.org/#/c/499239/

=> Migration fix-ups.
- Make live migration hold resources with a migration allocation:
https://review.openstack.org/#/c/507638/
- POST /allocations for multiple consumers:
https://review.openstack.org/#/c/500073/

=> GET /allocation_candidates - traits, sharing, and lots of tests.
Series starting at:
https://review.openstack.org/#/c/517027/

=> Symmetric get and put and post to /allocations:
https://review.openstack.org/#/c/510626/

Many thanks in advance.

[1]
http://eavesdrop.openstack.org/meetings/nova_scheduler/2017/nova_scheduler.2017-11-27-14.00.log.html
[2] https://etherpad.openstack.org/p/nova-ptg-queens-placement L47-55

__
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] Gerrit cleanup

[Lance Bragstad]

Hey all,

One of the items that came out of our retrospective was to cleanup stale
reviews in Gerrit [0]. I spent some time last week working on this and I
think I've cleaned up most things. All reviews I abandon should have a
clear reason why. If you find that is not the case, please don't
hesitate to ping me. If there is something you think is important and it
was abandon, let me know. We should be able to document it somewhere if
it isn't already, and find a new owner for it.

Thanks,

Lance

[0] https://trello.com/c/mPTqEHAD/63-cleanup-gerrit




signature.asc
Description: OpenPGP digital 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] [murano] Where can we find an image with Murano Agent

[Stan Lagun]

Hi Jerry,

Previously these images were available at apps.openstack.org. But since
this site is no longer available, the only way to get the images that I
know is to build them by yourself.
Here is how you can build most basic ubuntu+murano-agent image:
https://github.com/openstack/murano-agent/tree/master/contrib/elements
Some of the applications in the murano-apps repo require an image with
additional elements. They all come with instructions on how to build the
image.

But, if you are on a recent murano version, you can try to go with a bare
ubuntu cloud image since murano should be capable to install agent through
the cloud-init without backing it into the image.


Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Fri, Nov 24, 2017 at 11:05 AM, Sun, Yicheng (Jerry) <
jerry@windriver.com> wrote:

> We are trying to test our Murano deployment.
>
> We are working with the Pike version of Murano.
>
>
>
> Do you know where we can get an image with Murano Agent?
>
> The community application catalog was taken down.
>
> We tried following the instructions here:
>
> https://murano.readthedocs.io/en/latest/image_builders/linux.html
>
> https://pypi.python.org/pypi/murano-agent/3.3.0
>
>
>
> We were not able to build ubuntu with Murano Agent.
>
>
>
> Thanks in advance,
>
> Jerry
>
>
>
> __
> 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] [murano] Where can we find an image with Murano Agent

[Jeremy Stanley]

On 2017-11-27 09:04:23 -0800 (-0800), Stan Lagun wrote:
> Previously these images were available at apps.openstack.org. But
> since this site is no longer available, the only way to get the
> images that I know is to build them by yourself.
[...]

It merits mention that the reason apps.openstack.org and the
app-catalog project were discontinued was in an effort to avoid
confusion/competition with other more full-featured and established
application catalogs. Is there somewhere we (or someone) should
start publishing built images for Murano Agent?
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [octavia] connection to external network

[Michael Johnson]

Hello Volodymyr,

You have two options:
1. When you create your VIP, simply put in your external network as
the vip-subnet-id or vip-network-id. This will allocate a public IP to
the VIP.
2. Use neutron to assign a floating IP to the VIP address of the load
balancer.  From your example, let's say the VIP address of lb1 is
10.0.0.10 on the nbt-subnet with port ID
7e11e63e-7dcb-4b2c-835e-f5cd7ca79acf.  You would use "openstack
floating ip create --port 7e11e63e-7dcb-4b2c-835e-f5cd7ca79acf
external".  This will assign a floating IP to the VIP address.

Option 1 will have better performance as there is no NAT occurring
like there is with a floating IP.

Michael


On Mon, Nov 27, 2017 at 1:30 AM, Volodymyr Litovka  wrote:
> Hello colleagues,
>
> I think I'm missing something architectural in LBaaS / Octavia, thus asking
> there - how to connect Amphora agent to external network? My current lab
> topology is the following:
>
> +
> |
> |++
> +   ++ n1 |
> |+-+|++
> ++ Amphora ++
> |+-+|++
>   m | n ++ n2 |
>   g | b |+++ e
>   m | t |  | x
>   t |   |++| t
> | s ++ vR ++ e
> | u |++| r
>++ b |  | n
>| Controller | n |++| a
>++ e |+ n3 |+ l
>   t |++
> +
>
> where "Amphora" is agent which loadbalances requests between "n1" and "n2":
>
> openstack loadbalancer create --name lb1 --vip-subnet-id nbt-subnet
> --project bush
> openstack loadbalancer listener create --protocol TCP --protocol-port 80
> --name lis1 lb1
> openstack loadbalancer pool create --protocol TCP --listener lis1 --name
> lpool1 --lb-algorithm ROUND_ROBIN
> openstack loadbalancer member create --protocol-port 80 --name n1 --address
> 1.1.1.11 lpool1
> openstack loadbalancer member create --protocol-port 80 --name n2 --address
> 1.1.1.14 lpool1
>
> Everything works (n3-sourced connections to Amphora-agent return answers
> from n1 and n2 respectively in round robin way) and the question is how to
> connect Amphora-agent to external network in order to service requests from
> outside?
>
> In example above, nbt-subnet (which is VIP network) has a virtual router
> which is connected to external network and has all abilities to provide e.g.
> floating ip to Amphora, but I see nothing in octavia config files regarding
> floating ip functions.
>
> Am I missing something? Any ways on connect Web-servers in closed
> (project's) networks with Internet using Octavia / LBaaS?
>
> Thank you!
>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
>
>
> __
> 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] [designate] Meeting Time

[Graham Hayes]

On 22/11/17 17:16, Graham Hayes wrote:
> So, after looking at the responses, we have a winning
> meeting time.
> 
> 14:00 UTC (I propose staying on Wednesday) [1].
> 
> If there is no objections by the end of the week, I will
> update the meeting time on eavesdrop.openstack.org
> 
> Thanks,
> 
> Graham
> 
> 1 -
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171129T14&p1=1440
> 

I have submitted [1] to change our meeting time - it will now be

14:00 UTC on Wednesdays in #openstack-meeting

Thanks,

Graham

1 - https://review.openstack.org/#/c/523177/



signature.asc
Description: OpenPGP digital 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

[openstack-dev] Sydne Summit Project Onboarding Retrospective

[Kendall Nelson]

Hello Everyone :)

I hope you all had a good summit and a little bit of time to reflect on how
things went. I wanted to collect some information about how things went and
how to improve for Vancouver.

--

Feedback from last round to keep in mind:



   -

   Minimize conflicts between other Summit talks and the onboarding session
   going on
   -

   Recording the sessions
   -

   Bigger rooms?
   -

   Make sure attendees and project reps are aware of what it covered in the
   upstream training
   -

   Could advertise more
   -

   Don’t overlap or go up until happy hour if possible ;)
   -

   Have different options of durations for projects to sign up for



This round we addressed some of these things:

   - This time I tried to focus a bit more on collecting speakers before
   hand and double checking there weren't conflicts with other presentations
   scheduled.
   - Got bigger rooms :)
   - Time slots were tweaked to be smaller but gave extra time to those
   that asked for it.
   - Advertised the project onboarding rooms at Upstream Institute
   (Saturday/Sunday before the summit) and at the WoO Speed Mentoring Session
   (Monday lunchtime).

Things I see as improvements for next time still:

   - Obviously, people still want recordings :)
   - Trying to schedule the onboarding rooms to precede or follow project
   updates?
   - Advertise more
   - Unify on set of topics for onboarding rooms to cover- i.e code
   structure/ what sub repos exist/ how to run unit tests/ who works on the
   project

I created an etherpad to continue this discussion[1]. Please add to the
list of improvements for next time, as I know there are more than 4 things
to improve on. Also, if you have ideas for how to make these improvements,
please add those to the etherpad as well.

I think onboarding new project members is incredibly important for the
future success of OpenStack. Help me make it better :)

Thanks!

-Kendall Nelson (diablo_rojo)

[1] https://etherpad.openstack.org/p/SYD_Onboarding_Retrospective
__
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] Community managed tech/dev blog: Call for opinions and ideas

[Joshua Harlow]

Flavio Percoco wrote:

Greetings,

Last Thursday[0], at the TC office hours, we brainstormed a bit around
the idea
of having a tech blog. This idea came first from Joshua Harlow and it
was then
briefly discussed at the summit too.

The idea, we have gathered, is to have a space where the community could
write
technical posts about OpenStack. The idea is not to have an aggregator
(that's
what our planet[1] is for) but a place to write original and curated
content.
During the conversation, we argued about what kind of content would be
acceptable for this platform. Here are some ideas of things we could
have there:

- Posts that are dev-oriented (e.g: new functions on an oslo lib)
- Posts that facilitate upstream development (e.g: My awesome dev setup)
- Deep dive into libvirt internals
- ideas?

As Chris Dent pointed out on that conversation, we should avoid making this
place a replacement for things that would otherwise go on the mailing
list -
activity reports, for example. Having dev news in this platform, we would
overlap with things that go already on the mailing list and, arguably,
we would
be defeating the purpose of the platform. But, there might be room for
both(?)

Ultimately, we should avoid topics promoting new features in services as
that's what
superuser[2] is for.

So, what are your thoughts about this? What kind of content would you
rather
have posted here? Do you like the idea at all?


Yes, I like it :)

I want a place that is like http://blog.kubernetes.io/

With say an editor that solicits (and backlogs topics and stories and 
such) various developers/architects at various companies and creates a 
actually human curated place for developers and technology and 
architecture to be spot-lighted.


To me personal blogs can be used for this, sure, but that sort of misses 
the point of having a place that is targeted for this (and no I don't 
really care about finding and subscribing to 100+ random joe blogs that 
I will never look at more than once). Ideally that place would not 
become `elitist` as some others have mentioned in this thread (ie, don't 
pick an elitist editor? lol).


The big desire for me is to actually have a editor (a person or people) 
involved that is keeping such a blog going and editing it and curating 
it and ensuring it gets found in google searches and is *developer* 
focused...




[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-11-23.log.html#t2017-11-23T15:01:25

[1] http://planet.openstack.org/
[2] http://superuser.openstack.org/

Flavio

--
@flaper87
Flavio Percoco

__
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] [kolla] Ansiblize init-runonce script

[Ravi Shekhar Jethani]

Hi,

While exploring kolla-ansible I ran into a few issues with
init-runonce script. This lead to following bugs and patches:

https://launchpad.net/bugs/1732963
https://review.openstack.org/51
https://review.openstack.org/521190

But it was highlighted that instead of fixing/changing the
script, 'ansibilzing' it would be the ideal solution.
Hence I hereby formally propose the same.

My thoughts:
* Playbook Name: init-stack.yml

* Playbook path can be:
kolla-ansible/ansible/init-stack.yml

* The play can be executed like:
$ kolla-ansible init-stack -i 

* The cirros test image should be downloaded in /tmp

* What should be the behavior if the play is run multiple times
against the same stack?
  - some error message OR
  - simply ignore the action

Kindly provide suggestions.

--
Best Regards,
Ravi J.

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Jay Pipes]

On 11/27/2017 01:54 PM, Joshua Harlow wrote:

I want a place that is like http://blog.kubernetes.io/


You know that's not for developers (only) of k8s, right? That's for 
users, marketers, product managers, etc.


So, when you say *for developers*, what exactly do you mean? Are you 
referring to developers of OpenStack projects or are you referring to 
*users* of cloud services -- i.e. application developers?


Best,
-jay

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2017-11-27 10:54:02 -0800:
> Flavio Percoco wrote:
> > Greetings,
> >
> > Last Thursday[0], at the TC office hours, we brainstormed a bit around
> > the idea
> > of having a tech blog. This idea came first from Joshua Harlow and it
> > was then
> > briefly discussed at the summit too.
> >
> > The idea, we have gathered, is to have a space where the community could
> > write
> > technical posts about OpenStack. The idea is not to have an aggregator
> > (that's
> > what our planet[1] is for) but a place to write original and curated
> > content.
> > During the conversation, we argued about what kind of content would be
> > acceptable for this platform. Here are some ideas of things we could
> > have there:
> >
> > - Posts that are dev-oriented (e.g: new functions on an oslo lib)
> > - Posts that facilitate upstream development (e.g: My awesome dev setup)
> > - Deep dive into libvirt internals
> > - ideas?
> >
> > As Chris Dent pointed out on that conversation, we should avoid making this
> > place a replacement for things that would otherwise go on the mailing
> > list -
> > activity reports, for example. Having dev news in this platform, we would
> > overlap with things that go already on the mailing list and, arguably,
> > we would
> > be defeating the purpose of the platform. But, there might be room for
> > both(?)
> >
> > Ultimately, we should avoid topics promoting new features in services as
> > that's what
> > superuser[2] is for.
> >
> > So, what are your thoughts about this? What kind of content would you
> > rather
> > have posted here? Do you like the idea at all?
> 
> Yes, I like it :)
> 
> I want a place that is like http://blog.kubernetes.io/
> 
> With say an editor that solicits (and backlogs topics and stories and 
> such) various developers/architects at various companies and creates a 
> actually human curated place for developers and technology and 
> architecture to be spot-lighted.
> 
> To me personal blogs can be used for this, sure, but that sort of misses 
> the point of having a place that is targeted for this (and no I don't 
> really care about finding and subscribing to 100+ random joe blogs that 
> I will never look at more than once). Ideally that place would not 
> become `elitist` as some others have mentioned in this thread (ie, don't 
> pick an elitist editor? lol).
> 
> The big desire for me is to actually have a editor (a person or people) 
> involved that is keeping such a blog going and editing it and curating 
> it and ensuring it gets found in google searches and is *developer* 
> focused...

Are you volunteering? :-)

Doug

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Jimmy McArthur]

Joshua Harlow wrote:
With say an editor that solicits (and backlogs topics and stories and 
such) various developers/architects at various companies and creates a 
actually human curated place for developers and technology and 
architecture to be spot-lighted.


To me personal blogs can be used for this, sure, but that sort of 
misses the point of having a place that is targeted for this (and no I 
don't really care about finding and subscribing to 100+ random joe 
blogs that I will never look at more than once). Ideally that place 
would not become `elitist` as some others have mentioned in this 
thread (ie, don't pick an elitist editor? lol).


The big desire for me is to actually have a editor (a person or 
people) involved that is keeping such a blog going and editing it and 
curating it and ensuring it gets found in google searches and is 
*developer* focused... 


This is basically what https://www.openstack.org/blog/ is for. It's 
using Wordpress. It's developer-centric. Anyone can submit to it and we 
have editors that can publish it. We also have pretty solid SEO.
__
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] Dublin PTG format

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-11-27 11:58:04 +0100:
> Hi everyone,
> 
> We are in the final step in the process of signing the contract with the
> PTG venue. We should be able to announce the location this week !
> 
> So it's time to start preparing. We'll have 5 days, like in Denver. One
> thing we'd like to change for this round is to give a bit more
> flexibility in the topics being discussed, especially in the first two days.
> 
> In Denver, we selected a number of general "themes" and gave them all a
> room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> project team meeting could get a room for 2 or 3 days on
> Wednesday-Friday. That resulted in a bit of flux during the first two
> days, with a lot of empty rooms as most of the themes did not really
> need 2 days, and a lot of conflicts were present.
> 
> For Dublin, the idea would be to still predetermine topics (themes and
> teams) and assign them rooms in advance. But we would be able to assign
> smaller amounts of time (per half-day) based on the expressed needs.
> Beyond those pre-assigned themes/teams we'd add flexibility for other
> groups to book the remaining available rooms in 90-min slots on-demand.
> A bit like how we did reservable rooms in the past, but more integrated
> with the rest of the event. It would all be driven by the PTGbot, which
> would show which topic is being discussed in which room, in addition to
> the current discussion subject within each topic.
> 
> We have two options in how we do the split for predetermined topics. We
> used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> general idea there was to allow some people only interested in a team
> meeting to only attend the second part of the week. However most people
> attend all 5 days, and during event feedback some people suggested that
> "themes" should be in the mornings and "teams" in the afternoons (and
> all Friday).
> 
> What would be your preference ? The Mon-Tue/Wed-Fri split means less
> room changes, which make it easier on the events team. So all else being
> equal we'd rather keep it the way it is, but I'm open to changing it if
> attendees think it's a good idea.
> 
> If you have any other suggestion (that we could implement in the 3
> months we have between now and the event) please let me know :)
> 

What sort of options do we have for trying the new morning/afternoon
split approach without increasing the burden on the events team?

Can we print the signs so they have both the project team names and
a theme listed on the same sign so we can avoid changing them at
all?

Can we have the project teams or theme room organizers manage their
own signs, placing them in prepared holders outside of the rooms?

Or do we need signs at all? The rooms all have names or numbers
already right?

Doug

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Joshua Harlow]

Doug Hellmann wrote:

Excerpts from Joshua Harlow's message of 2017-11-27 10:54:02 -0800:

Flavio Percoco wrote:

Greetings,

Last Thursday[0], at the TC office hours, we brainstormed a bit around
the idea
of having a tech blog. This idea came first from Joshua Harlow and it
was then
briefly discussed at the summit too.

The idea, we have gathered, is to have a space where the community could
write
technical posts about OpenStack. The idea is not to have an aggregator
(that's
what our planet[1] is for) but a place to write original and curated
content.
During the conversation, we argued about what kind of content would be
acceptable for this platform. Here are some ideas of things we could
have there:

- Posts that are dev-oriented (e.g: new functions on an oslo lib)
- Posts that facilitate upstream development (e.g: My awesome dev setup)
- Deep dive into libvirt internals
- ideas?

As Chris Dent pointed out on that conversation, we should avoid making this
place a replacement for things that would otherwise go on the mailing
list -
activity reports, for example. Having dev news in this platform, we would
overlap with things that go already on the mailing list and, arguably,
we would
be defeating the purpose of the platform. But, there might be room for
both(?)

Ultimately, we should avoid topics promoting new features in services as
that's what
superuser[2] is for.

So, what are your thoughts about this? What kind of content would you
rather
have posted here? Do you like the idea at all?

Yes, I like it :)

I want a place that is like http://blog.kubernetes.io/

With say an editor that solicits (and backlogs topics and stories and
such) various developers/architects at various companies and creates a
actually human curated place for developers and technology and
architecture to be spot-lighted.

To me personal blogs can be used for this, sure, but that sort of misses
the point of having a place that is targeted for this (and no I don't
really care about finding and subscribing to 100+ random joe blogs that
I will never look at more than once). Ideally that place would not
become `elitist` as some others have mentioned in this thread (ie, don't
pick an elitist editor? lol).

The big desire for me is to actually have a editor (a person or people)
involved that is keeping such a blog going and editing it and curating
it and ensuring it gets found in google searches and is *developer*
focused...


Are you volunteering? :-)


You don't want me to be an editor ;)



Doug

__
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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Joshua Harlow]

Jay Pipes wrote:

On 11/27/2017 01:54 PM, Joshua Harlow wrote:

I want a place that is like http://blog.kubernetes.io/


You know that's not for developers (only) of k8s, right? That's for
users, marketers, product managers, etc.


We don't have to exactly copy it (that was not the intention).

But looking at the following it seems like its slightly more than that.

'This post is written by Kelsey Hightower, Staff Developer Advocate at 
Google, and Sandra Guo, Product Manager at Google.'


'Today's post is by Lantao Liu, Software Engineer at Google, and Mike 
Brown, Open Source Developer Advocate at IBM.'


'Editor's note: this post is part of a series of in-depth articles on 
what's new in Kubernetes 1.8. Today’s post comes from Ahmet Alp Balkan, 
Software Engineer, Google.'


'Editor's note: Today’s post by Frank Budinsky, Software Engineer, IBM, 
Andra Cismaru, Software Engineer, Google, and Israel Shalom, Product 
Manager, Google, is the second post in a three-part series on Istio. It 
offers a closer look at request routing and policy management.'


^ A lot of engineers in that (not just product folks, though there are 
some yes..).




So, when you say *for developers*, what exactly do you mean? Are you
referring to developers of OpenStack projects or are you referring to
*users* of cloud services -- i.e. application developers?


People like jay and josh and dims and ..., or future jay (jr) and josh 
(jr) folks...



Best,
-jay

__
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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Allison Price]

I agree with Jimmy that openstack.org/blog would be a great location for 
content like this, especially since the main piece of content is the 
OpenStack-dev ML digest that Mike creates weekly. Like Flavio mentioned, 
Superuser is another resource we can leverage for tutorials or new features. 
Both the blog and Superuser are Wordpress, enabling contributions from anyone 
with a login and content to share.

Superuser and the OpenStack blog is already syndicated with Planet OpenStack 
for folks who have already subscribed to the Planet OpenStack feed. 

Allison

Allison Price
OpenStack Foundation Marketing
alli...@openstack.org



> On Nov 27, 2017, at 1:44 PM, Joshua Harlow  wrote:
> 
> Doug Hellmann wrote:
>> Excerpts from Joshua Harlow's message of 2017-11-27 10:54:02 -0800:
>>> Flavio Percoco wrote:
 Greetings,
 
 Last Thursday[0], at the TC office hours, we brainstormed a bit around
 the idea
 of having a tech blog. This idea came first from Joshua Harlow and it
 was then
 briefly discussed at the summit too.
 
 The idea, we have gathered, is to have a space where the community could
 write
 technical posts about OpenStack. The idea is not to have an aggregator
 (that's
 what our planet[1] is for) but a place to write original and curated
 content.
 During the conversation, we argued about what kind of content would be
 acceptable for this platform. Here are some ideas of things we could
 have there:
 
 - Posts that are dev-oriented (e.g: new functions on an oslo lib)
 - Posts that facilitate upstream development (e.g: My awesome dev setup)
 - Deep dive into libvirt internals
 - ideas?
 
 As Chris Dent pointed out on that conversation, we should avoid making this
 place a replacement for things that would otherwise go on the mailing
 list -
 activity reports, for example. Having dev news in this platform, we would
 overlap with things that go already on the mailing list and, arguably,
 we would
 be defeating the purpose of the platform. But, there might be room for
 both(?)
 
 Ultimately, we should avoid topics promoting new features in services as
 that's what
 superuser[2] is for.
 
 So, what are your thoughts about this? What kind of content would you
 rather
 have posted here? Do you like the idea at all?
>>> Yes, I like it :)
>>> 
>>> I want a place that is like http://blog.kubernetes.io/
>>> 
>>> With say an editor that solicits (and backlogs topics and stories and
>>> such) various developers/architects at various companies and creates a
>>> actually human curated place for developers and technology and
>>> architecture to be spot-lighted.
>>> 
>>> To me personal blogs can be used for this, sure, but that sort of misses
>>> the point of having a place that is targeted for this (and no I don't
>>> really care about finding and subscribing to 100+ random joe blogs that
>>> I will never look at more than once). Ideally that place would not
>>> become `elitist` as some others have mentioned in this thread (ie, don't
>>> pick an elitist editor? lol).
>>> 
>>> The big desire for me is to actually have a editor (a person or people)
>>> involved that is keeping such a blog going and editing it and curating
>>> it and ensuring it gets found in google searches and is *developer*
>>> focused...
>> 
>> Are you volunteering? :-)
> 
> You don't want me to be an editor ;)
> 
>> 
>> Doug
>> 
>> __
>> 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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2017-11-27 11:44:54 -0800:
> Doug Hellmann wrote:
> > Excerpts from Joshua Harlow's message of 2017-11-27 10:54:02 -0800:
> >> Flavio Percoco wrote:
> >>> Greetings,
> >>>
> >>> Last Thursday[0], at the TC office hours, we brainstormed a bit around
> >>> the idea
> >>> of having a tech blog. This idea came first from Joshua Harlow and it
> >>> was then
> >>> briefly discussed at the summit too.
> >>>
> >>> The idea, we have gathered, is to have a space where the community could
> >>> write
> >>> technical posts about OpenStack. The idea is not to have an aggregator
> >>> (that's
> >>> what our planet[1] is for) but a place to write original and curated
> >>> content.
> >>> During the conversation, we argued about what kind of content would be
> >>> acceptable for this platform. Here are some ideas of things we could
> >>> have there:
> >>>
> >>> - Posts that are dev-oriented (e.g: new functions on an oslo lib)
> >>> - Posts that facilitate upstream development (e.g: My awesome dev setup)
> >>> - Deep dive into libvirt internals
> >>> - ideas?
> >>>
> >>> As Chris Dent pointed out on that conversation, we should avoid making 
> >>> this
> >>> place a replacement for things that would otherwise go on the mailing
> >>> list -
> >>> activity reports, for example. Having dev news in this platform, we would
> >>> overlap with things that go already on the mailing list and, arguably,
> >>> we would
> >>> be defeating the purpose of the platform. But, there might be room for
> >>> both(?)
> >>>
> >>> Ultimately, we should avoid topics promoting new features in services as
> >>> that's what
> >>> superuser[2] is for.
> >>>
> >>> So, what are your thoughts about this? What kind of content would you
> >>> rather
> >>> have posted here? Do you like the idea at all?
> >> Yes, I like it :)
> >>
> >> I want a place that is like http://blog.kubernetes.io/
> >>
> >> With say an editor that solicits (and backlogs topics and stories and
> >> such) various developers/architects at various companies and creates a
> >> actually human curated place for developers and technology and
> >> architecture to be spot-lighted.
> >>
> >> To me personal blogs can be used for this, sure, but that sort of misses
> >> the point of having a place that is targeted for this (and no I don't
> >> really care about finding and subscribing to 100+ random joe blogs that
> >> I will never look at more than once). Ideally that place would not
> >> become `elitist` as some others have mentioned in this thread (ie, don't
> >> pick an elitist editor? lol).
> >>
> >> The big desire for me is to actually have a editor (a person or people)
> >> involved that is keeping such a blog going and editing it and curating
> >> it and ensuring it gets found in google searches and is *developer*
> >> focused...
> >
> > Are you volunteering? :-)
> 
> You don't want me to be an editor ;)

I think you'd be great as an Acquisitions Editor. That's a role at
a publisher that goes out looking for people to write about interesting
things, sometimes starting with the topic and finding the person
and sometimes vice versa. To launch something like this, we need
someone to recruit writers. You have a good eye for "interesting"
and you clearly have a vision for what this content should look
like. Give it some thought.

Doug

__
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] Community managed tech/dev blog: Call for opinions and ideas

[Joshua Harlow]

How does one get a login or submit things to openstack.org/blog?

Is there any editor actively seeking out things (and reviewing) for 
folks to write (a part time job I would assume?).


Josh

Allison Price wrote:

I agree with Jimmy that openstack.org/blog 
would be a great location for content like this, especially since the
main piece of content is the OpenStack-dev ML digest that Mike creates
weekly. Like Flavio mentioned, Superuser is another resource we can
leverage for tutorials or new features. Both the blog and Superuser are
Wordpress, enabling contributions from anyone with a login and content
to share.

Superuser and the OpenStack blog is already syndicated with Planet
OpenStack for folks who have already subscribed to the Planet OpenStack
feed.

Allison

Allison Price
OpenStack Foundation Marketing
alli...@openstack.org 




On Nov 27, 2017, at 1:44 PM, Joshua Harlow mailto:harlo...@fastmail.com>> wrote:

Doug Hellmann wrote:

Excerpts from Joshua Harlow's message of 2017-11-27 10:54:02 -0800:

Flavio Percoco wrote:

Greetings,

Last Thursday[0], at the TC office hours, we brainstormed a bit around
the idea
of having a tech blog. This idea came first from Joshua Harlow and it
was then
briefly discussed at the summit too.

The idea, we have gathered, is to have a space where the community
could
write
technical posts about OpenStack. The idea is not to have an aggregator
(that's
what our planet[1] is for) but a place to write original and curated
content.
During the conversation, we argued about what kind of content would be
acceptable for this platform. Here are some ideas of things we could
have there:

- Posts that are dev-oriented (e.g: new functions on an oslo lib)
- Posts that facilitate upstream development (e.g: My awesome dev
setup)
- Deep dive into libvirt internals
- ideas?

As Chris Dent pointed out on that conversation, we should avoid
making this
place a replacement for things that would otherwise go on the mailing
list -
activity reports, for example. Having dev news in this platform, we
would
overlap with things that go already on the mailing list and, arguably,
we would
be defeating the purpose of the platform. But, there might be room for
both(?)

Ultimately, we should avoid topics promoting new features in
services as
that's what
superuser[2] is for.

So, what are your thoughts about this? What kind of content would you
rather
have posted here? Do you like the idea at all?

Yes, I like it :)

I want a place that is like http://blog.kubernetes.io/

With say an editor that solicits (and backlogs topics and stories and
such) various developers/architects at various companies and creates a
actually human curated place for developers and technology and
architecture to be spot-lighted.

To me personal blogs can be used for this, sure, but that sort of misses
the point of having a place that is targeted for this (and no I don't
really care about finding and subscribing to 100+ random joe blogs that
I will never look at more than once). Ideally that place would not
become `elitist` as some others have mentioned in this thread (ie, don't
pick an elitist editor? lol).

The big desire for me is to actually have a editor (a person or people)
involved that is keeping such a blog going and editing it and curating
it and ensuring it gets found in google searches and is *developer*
focused...


Are you volunteering? :-)


You don't want me to be an editor ;)



Doug

__
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


__
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] Community managed tech/dev blog: Call for opinions and ideas

[Allison Price]

Either Jimmy or I can help community members get a login to the blog, and once 
a post is ready to be published, either of us could push it live. 

We do not have someone that is currently seeking out content for the blog. 
Superuser is managed more closely on a day-to-day basis with a more traditional 
editorial process. If there is anyone from the dev community that would like to 
help seek out content / contributors, that would be welcomed and greatly 
appreciated. 

Cheers,
Allison

Allison Price
OpenStack Foundation
alli...@openstack.org


> On Nov 27, 2017, at 2:01 PM, Joshua Harlow  wrote:
> 
> How does one get a login or submit things to openstack.org/blog?
> 
> Is there any editor actively seeking out things (and reviewing) for folks to 
> write (a part time job I would assume?).
> 
> Josh
> 
> Allison Price wrote:
>> I agree with Jimmy that openstack.org/blog 
>> would be a great location for content like this, especially since the
>> main piece of content is the OpenStack-dev ML digest that Mike creates
>> weekly. Like Flavio mentioned, Superuser is another resource we can
>> leverage for tutorials or new features. Both the blog and Superuser are
>> Wordpress, enabling contributions from anyone with a login and content
>> to share.
>> 
>> Superuser and the OpenStack blog is already syndicated with Planet
>> OpenStack for folks who have already subscribed to the Planet OpenStack
>> feed.
>> 
>> Allison
>> 
>> Allison Price
>> OpenStack Foundation Marketing
>> alli...@openstack.org 
>> 
>> 
>> 
>>> On Nov 27, 2017, at 1:44 PM, Joshua Harlow >> > wrote:
>>> 
>>> Doug Hellmann wrote:
 Excerpts from Joshua Harlow's message of 2017-11-27 10:54:02 -0800:
> Flavio Percoco wrote:
>> Greetings,
>> 
>> Last Thursday[0], at the TC office hours, we brainstormed a bit around
>> the idea
>> of having a tech blog. This idea came first from Joshua Harlow and it
>> was then
>> briefly discussed at the summit too.
>> 
>> The idea, we have gathered, is to have a space where the community
>> could
>> write
>> technical posts about OpenStack. The idea is not to have an aggregator
>> (that's
>> what our planet[1] is for) but a place to write original and curated
>> content.
>> During the conversation, we argued about what kind of content would be
>> acceptable for this platform. Here are some ideas of things we could
>> have there:
>> 
>> - Posts that are dev-oriented (e.g: new functions on an oslo lib)
>> - Posts that facilitate upstream development (e.g: My awesome dev
>> setup)
>> - Deep dive into libvirt internals
>> - ideas?
>> 
>> As Chris Dent pointed out on that conversation, we should avoid
>> making this
>> place a replacement for things that would otherwise go on the mailing
>> list -
>> activity reports, for example. Having dev news in this platform, we
>> would
>> overlap with things that go already on the mailing list and, arguably,
>> we would
>> be defeating the purpose of the platform. But, there might be room for
>> both(?)
>> 
>> Ultimately, we should avoid topics promoting new features in
>> services as
>> that's what
>> superuser[2] is for.
>> 
>> So, what are your thoughts about this? What kind of content would you
>> rather
>> have posted here? Do you like the idea at all?
> Yes, I like it :)
> 
> I want a place that is like http://blog.kubernetes.io/
> 
> With say an editor that solicits (and backlogs topics and stories and
> such) various developers/architects at various companies and creates a
> actually human curated place for developers and technology and
> architecture to be spot-lighted.
> 
> To me personal blogs can be used for this, sure, but that sort of misses
> the point of having a place that is targeted for this (and no I don't
> really care about finding and subscribing to 100+ random joe blogs that
> I will never look at more than once). Ideally that place would not
> become `elitist` as some others have mentioned in this thread (ie, don't
> pick an elitist editor? lol).
> 
> The big desire for me is to actually have a editor (a person or people)
> involved that is keeping such a blog going and editing it and curating
> it and ensuring it gets found in google searches and is *developer*
> focused...
 
 Are you volunteering? :-)
>>> 
>>> You don't want me to be an editor ;)
>>> 
 
 Doug
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org
 ?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/list

Re: [openstack-dev] [OpenStack] [Networking-odl] [Qos] networking-odl is not sending complete data during qos-policy-name update

[Isaku Yamahata]

Added odl neutron-dev.
Basically this issue is fixed with master already.
As newton is about to be EOL, I don't see any point to dig into it.

Probably you'd like to check the fix in the master and backport it to newton.

Thanks,


On Tue, Nov 21, 2017 at 10:08:03AM +,
A Vamsikrishna  wrote:

> Hi All,
> 
> Networking-odl is not sending bandwidth_limit_rules & dscp_marking_rules 
> along with the updated qos policy name when I have updated the 
> qos-policy-name from Vamsi to Krish.
> 
> Expected behavior is to have the updated policy name along with 
> bandwidth_limit_rules & dscp_marking_rules same as that in old 
> qos-policy-name.
> 
> 
> 
> Version: Stable/Newton
> 192.168.56.102 --> Openstack
> 192.168.56.1 --> ODL
> 
> Any thoughts on how to move forward ?
> 
> PFA for wireshark cap.
> 
> JavaScript Object Notation: application/json
> Object
> Member Key: policy
> Object
> Member Key: bandwidth_limit_rules
> Array
> Key: bandwidth_limit_rules
> Member Key: name
> String value: Krish
> Key: name
> Member Key: created_at
> String value: 2017-11-20T19:27:06Z
> Key: created_at
> Member Key: updated_at
> String value: 2017-11-20T19:27:15Z
> Key: updated_at
> Member Key: dscp_marking_rules
> Array
> Key: dscp_marking_rules
> Member Key: revision_number
> Number value: 4
> Key: revision_number
> Member Key: shared
> False value
> Key: shared
> Member Key: project_id
> String value: eacd04d3ff4b4e1d9dc2f5282edbb9e0
> Key: project_id
> Member Key: id
> String value: 066fd21e-2041-43f6-956a-6bec0948bf15
> Key: id
> Member Key: description
> String value:
> Key: description
> Key: policy
> 
> 
> Thanks,
> Vamsi


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


-- 
Isaku Yamahata 

__
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] Dublin PTG format

[Jay Bryant]

Thierry,

I have been happy with the current 2 day/3 day split.  I am concerned that
I would have a harder time getting focus from the project team splitting
across multiple half days.  That is just my hunch.

Jay

On Mon, Nov 27, 2017, 1:21 PM Doug Hellmann  wrote:

> Excerpts from Thierry Carrez's message of 2017-11-27 11:58:04 +0100:
> > Hi everyone,
> >
> > We are in the final step in the process of signing the contract with the
> > PTG venue. We should be able to announce the location this week !
> >
> > So it's time to start preparing. We'll have 5 days, like in Denver. One
> > thing we'd like to change for this round is to give a bit more
> > flexibility in the topics being discussed, especially in the first two
> days.
> >
> > In Denver, we selected a number of general "themes" and gave them all a
> > room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> > project team meeting could get a room for 2 or 3 days on
> > Wednesday-Friday. That resulted in a bit of flux during the first two
> > days, with a lot of empty rooms as most of the themes did not really
> > need 2 days, and a lot of conflicts were present.
> >
> > For Dublin, the idea would be to still predetermine topics (themes and
> > teams) and assign them rooms in advance. But we would be able to assign
> > smaller amounts of time (per half-day) based on the expressed needs.
> > Beyond those pre-assigned themes/teams we'd add flexibility for other
> > groups to book the remaining available rooms in 90-min slots on-demand.
> > A bit like how we did reservable rooms in the past, but more integrated
> > with the rest of the event. It would all be driven by the PTGbot, which
> > would show which topic is being discussed in which room, in addition to
> > the current discussion subject within each topic.
> >
> > We have two options in how we do the split for predetermined topics. We
> > used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> > general idea there was to allow some people only interested in a team
> > meeting to only attend the second part of the week. However most people
> > attend all 5 days, and during event feedback some people suggested that
> > "themes" should be in the mornings and "teams" in the afternoons (and
> > all Friday).
> >
> > What would be your preference ? The Mon-Tue/Wed-Fri split means less
> > room changes, which make it easier on the events team. So all else being
> > equal we'd rather keep it the way it is, but I'm open to changing it if
> > attendees think it's a good idea.
> >
> > If you have any other suggestion (that we could implement in the 3
> > months we have between now and the event) please let me know :)
> >
>
> What sort of options do we have for trying the new morning/afternoon
> split approach without increasing the burden on the events team?
>
> Can we print the signs so they have both the project team names and
> a theme listed on the same sign so we can avoid changing them at
> all?
>
> Can we have the project teams or theme room organizers manage their
> own signs, placing them in prepared holders outside of the rooms?
>
> Or do we need signs at all? The rooms all have names or numbers
> already right?
>
> Doug
>
> __
> 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] [Networking-odl] [Qos] networking-odl is not sending complete data during qos-policy-name update

[Sławek Kapłoński]

Hi,

I checked that on Neutron’s side and I proposed patch to fix it in Ocata: 
https://review.openstack.org/#/c/523133/
I think that this patch from Ocata should be easy to back port to newton also 
if You will need it there.
It is fixed in Pike already.

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Isaku Yamahata  w dniu 
> 22.11.2017, o godz. 02:17:
> 
> Added odl neutron-dev.
> Basically this issue is fixed with master already.
> As newton is about to be EOL, I don't see any point to dig into it.
> 
> Probably you'd like to check the fix in the master and backport it to newton.
> 
> Thanks,
> 
> 
> On Tue, Nov 21, 2017 at 10:08:03AM +,
> A Vamsikrishna  wrote:
> 
>> Hi All,
>> 
>> Networking-odl is not sending bandwidth_limit_rules & dscp_marking_rules 
>> along with the updated qos policy name when I have updated the 
>> qos-policy-name from Vamsi to Krish.
>> 
>> Expected behavior is to have the updated policy name along with 
>> bandwidth_limit_rules & dscp_marking_rules same as that in old 
>> qos-policy-name.
>> 
>> 
>> 
>> Version: Stable/Newton
>> 192.168.56.102 --> Openstack
>> 192.168.56.1 --> ODL
>> 
>> Any thoughts on how to move forward ?
>> 
>> PFA for wireshark cap.
>> 
>> JavaScript Object Notation: application/json
>>Object
>>Member Key: policy
>>Object
>>Member Key: bandwidth_limit_rules
>>Array
>>Key: bandwidth_limit_rules
>>Member Key: name
>>String value: Krish
>>Key: name
>>Member Key: created_at
>>String value: 2017-11-20T19:27:06Z
>>Key: created_at
>>Member Key: updated_at
>>String value: 2017-11-20T19:27:15Z
>>Key: updated_at
>>Member Key: dscp_marking_rules
>>Array
>>Key: dscp_marking_rules
>>Member Key: revision_number
>>Number value: 4
>>Key: revision_number
>>Member Key: shared
>>False value
>>Key: shared
>>Member Key: project_id
>>String value: eacd04d3ff4b4e1d9dc2f5282edbb9e0
>>Key: project_id
>>Member Key: id
>>String value: 066fd21e-2041-43f6-956a-6bec0948bf15
>>Key: id
>>Member Key: description
>>String value:
>>Key: description
>>Key: policy
>> 
>> 
>> Thanks,
>> Vamsi
> 
> 
>> __
>> 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
> 
> 
> --
> Isaku Yamahata 
> 
> __
> 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
__
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] [charms] [designate] Domain and server creation during deployment

[Dmitrii Shcherbakov]

Hi Liam,

We may do either of two but I think that we need to somehow make it
clear to a user that a setup is not over yet e.g. via a status string.
As a user you should be able to clear it if you want but I think we
need to provide guidance to somebody who doesn't have a full knowdledge
of all components in an OpenStack deployment.

In other words, if we cannot make it automatic, let's at least guide an
operator that there's more to do.

I think the idea of one-time actions is not that new and may be useful
here. Unless certain leader settings are not set a user would be warned
that this action is yet to be run to complete the setup or he has to
explicitly ignore it.

In my view, we should store enough configuration in leader settings so
that proper config rendering is possible during scale-out while domain
and nameserver creation can be offloaded to an operator.

Thanks,

Dmitrii Shcherbakov

__
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] Dublin PTG format

[Colleen Murphy]

On Mon, Nov 27, 2017 at 11:58 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> We are in the final step in the process of signing the contract with the
> PTG venue. We should be able to announce the location this week !
>
> So it's time to start preparing. We'll have 5 days, like in Denver. One
> thing we'd like to change for this round is to give a bit more
> flexibility in the topics being discussed, especially in the first two days.
>
> In Denver, we selected a number of general "themes" and gave them all a
> room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> project team meeting could get a room for 2 or 3 days on
> Wednesday-Friday. That resulted in a bit of flux during the first two
> days, with a lot of empty rooms as most of the themes did not really
> need 2 days, and a lot of conflicts were present.
>
> For Dublin, the idea would be to still predetermine topics (themes and
> teams) and assign them rooms in advance. But we would be able to assign
> smaller amounts of time (per half-day) based on the expressed needs.
> Beyond those pre-assigned themes/teams we'd add flexibility for other
> groups to book the remaining available rooms in 90-min slots on-demand.
> A bit like how we did reservable rooms in the past, but more integrated
> with the rest of the event. It would all be driven by the PTGbot, which
> would show which topic is being discussed in which room, in addition to
> the current discussion subject within each topic.
>
> We have two options in how we do the split for predetermined topics. We
> used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> general idea there was to allow some people only interested in a team
> meeting to only attend the second part of the week. However most people
> attend all 5 days, and during event feedback some people suggested that
> "themes" should be in the mornings and "teams" in the afternoons (and
> all Friday).
>
> What would be your preference ? The Mon-Tue/Wed-Fri split means less
> room changes, which make it easier on the events team. So all else being
> equal we'd rather keep it the way it is, but I'm open to changing it if
> attendees think it's a good idea.
>
> If you have any other suggestion (that we could implement in the 3
> months we have between now and the event) please let me know :)
>
> --
> Thierry Carrez (ttx)

I felt like the 2/3 day split worked well for the discussions I
participated in. We were able to come up with ideas and common
understanding in cross-project discussions on the first two days, and
then solidify a plan to implement those ideas within the team during
the last three days. The colocation of the project teams in the last
three days allowed us to pull other people in if we needed to revisit
something from the first two days. I'm not sure that changing the
split is solving a problem that we have.

Colleen

__
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] Dublin PTG format

[Sean McGinnis]

> 
> What sort of options do we have for trying the new morning/afternoon
> split approach without increasing the burden on the events team?
> 
> Can we print the signs so they have both the project team names and
> a theme listed on the same sign so we can avoid changing them at
> all?
> 

RaspberryPi powered displays that automatically pull data from the PTG bot?


__
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] Dublin PTG format

[Jeremy Freudberg]

-1 from me.

If one is a big name in OpenStack and/or has fingers in many pies,
then moving away from the 2/3 split makes sense. That is to say, if
you have the capacity for lots of interests, and lots of people are
interested in you, then flexible scheduling allows all those interests
to get satisfied.

But not every PTG atendee is like that. For example, I myself am a
full-time undergraduate student, who's essentially only works on
OpenStack (mostly Sahara) in his free time. I was fortunate enough to
attend PTGs in Atlanta and in Denver. And one of the main reasons I
was able to attend was because the Sahara team events were laid out as
_two consecutive marathon days_. Thanks, 2/3 split. Horizontal and
"theme" stuff is fun (and important to many), but not everyone has the
luxury of tacking on two extra days of extra stuff. My assumption is
that others for whom OpenStack contributions are a hobby and not part
of one's job probably share this sentiment, that we need to get-in and
get-out as quickly as we can, and can only really devote time to our
main project.


I also share Jay's intuition that it will be harder to get focus out
of several half-days then a few whole-days. For Sahara (at least from
my own observation) certainly that would be only the way to get enough
focus that we can really regroup, reset, and take stock of what we
have moving forward to the next dev cycle. A half-day feels disjointed
enough that it might as well be remote.

On Mon, Nov 27, 2017 at 5:58 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> We are in the final step in the process of signing the contract with the
> PTG venue. We should be able to announce the location this week !
>
> So it's time to start preparing. We'll have 5 days, like in Denver. One
> thing we'd like to change for this round is to give a bit more
> flexibility in the topics being discussed, especially in the first two days.
>
> In Denver, we selected a number of general "themes" and gave them all a
> room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> project team meeting could get a room for 2 or 3 days on
> Wednesday-Friday. That resulted in a bit of flux during the first two
> days, with a lot of empty rooms as most of the themes did not really
> need 2 days, and a lot of conflicts were present.
>
> For Dublin, the idea would be to still predetermine topics (themes and
> teams) and assign them rooms in advance. But we would be able to assign
> smaller amounts of time (per half-day) based on the expressed needs.
> Beyond those pre-assigned themes/teams we'd add flexibility for other
> groups to book the remaining available rooms in 90-min slots on-demand.
> A bit like how we did reservable rooms in the past, but more integrated
> with the rest of the event. It would all be driven by the PTGbot, which
> would show which topic is being discussed in which room, in addition to
> the current discussion subject within each topic.
>
> We have two options in how we do the split for predetermined topics. We
> used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> general idea there was to allow some people only interested in a team
> meeting to only attend the second part of the week. However most people
> attend all 5 days, and during event feedback some people suggested that
> "themes" should be in the mornings and "teams" in the afternoons (and
> all Friday).
>
> What would be your preference ? The Mon-Tue/Wed-Fri split means less
> room changes, which make it easier on the events team. So all else being
> equal we'd rather keep it the way it is, but I'm open to changing it if
> attendees think it's a good idea.
>
> If you have any other suggestion (that we could implement in the 3
> months we have between now and the event) please let me know :)
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. Midcycle planning: https://etherpad.openstack.org/p/ironic-queens-midcycle
2. Use adapters for cinderclient: https://review.openstack.org/#/c/476171/ 
MERGED
2.1. then also for inspector client: 
https://review.openstack.org/#/c/476172/ MERGED
3. install guide update for hw types: https://review.openstack.org/#/c/517290/
3.1. before that, separate pages for deploy and boot interfaces: 
https://review.openstack.org/#/c/517632/
4. BIOS interface spec: https://review.openstack.org/#/c/496481/
5. Rescue:
5.1. driver interface https://review.openstack.org/#/c/509335/
5.2. RPC https://review.openstack.org/#/c/509336/
5.3. rescuewait timeout https://review.openstack.org/#/c/353156

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/207337 - Out-of-band Boot from UEFI iSCSI 
volume for HPE Proliant server
irmc:
SPEC to add a new hardware type for another FUJITSU server: PRIMEQUEST MMB:
  https://review.openstack.org/#/c/515717/ MERGED

oneview:
Add validations for OneView ML2 driver -  
https://review.openstack.org/#/c/508946/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
  - dnsmasq-based inspector PXE filter driver: 
https://review.openstack.org/#/c/466448/ TL;DR: replaces iptables with a 
dynamic configuration of dnsmasq (pretty cool thing too ;)
- folks might consider trying the test patch to experiment manually with 
this https://review.openstack.org/#/c/468712/54
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 13 Nov 2017 and 20 Nov 2017)
- Ironic: 219 bugs (-4) + 254 wishlist items (+7). 11 new (-2), 153 in progress 
(+2), 0 critical, 31 high and 35 incomplete (+1)
- Inspector: 16 bugs + 31 wishlist items. 0 new (-2), 16 in progress, 0 
critical, 4 high and 5 incomplete (+2)
- Nova bugs with Ironic tag: 14 (+1). 2 new (+1), 0 critical, 1 high
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- gerrit topic: https://review.openstack.org/#/q/topic:bug/1671145
- status as of 20 Nov 2017:
- ironicclient default version change done, release as 2.0.0
- TODO:
- easier access to versions in ironicclient
- see 
https://etherpad.openstack.org/p/ironic-api-version-negotiation
-

[openstack-dev] The Infra Team is back to normal "office hours"

[Clark Boylan]

Hello everyone,

Just wanted to quickly let everyone know that with the majority of Zuul
v3 transition firefighting, Summit Travel, and the big US Thanksgiving
Holiday Weekend behind us the Infra team is resuming its normal "office
hours". That means you shouldn't feel like it is a bad time to ping us.
Please do talk to us if we can help with whatever problems related to
the infrastructure you are having.

Thank you for your patience,
Clark (for the rest of the Infra 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] Developer Mailing List Digest November 18-27

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-18-27/


Community Summaries
===
* Glance priorities [0]
* Nova placement resource provider update [1]
* Keystone Upcoming Deadlines [2]
* Ironic priorities and subteam reports [3]
* Keystone office hours [4]
* Nova notification update [5]
* Release countdown [6]
* Technical committee status update [7]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124678.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124429.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124727.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124731.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124820.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124900.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124882.html
[7] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124875.html


Self-healing SIG created


Adam Spiers announced the formation of a SIG around self-healing. Its scope is 
to coordinate the use and development of several OpenStack projects which can 
be combined in various ways to manage OpenStack infrastructure in a 
policy-driven fashion, reacting to failures and other events by automatically 
healing and optimising services.

Full thread: 
http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000170.html


Proposal for a QA SIG
=

A proposal to to have a co-existing QA special interest group (SIG) that would
be a place for downstream efforts to have a common place in collaborating and
sharing tests. Example today the OPNFV performs QA on OpenStack releases today
and are actively looking for opportunieis to share tools and test cases. While
a SIG can exist to do some code, the QA team will remain for now since there
are around 15 QA projects existing like Tempest and Grenade.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124662


Improving the Process for Release Marketing
===

Collecting and summarizing "top features" during release time is difficult for
both PTL's and Foundation marketing. A system is now in place for PTL's to
highlight release notes [0]. Foundation marketing will work with the various
teams if needed to understand and make things more press friendly.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124726

[0] - http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466

-- 
Mike Perez (thingee)


pgp4aZbH06Cqz.pgp
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] [all] Dublin PTG format

[Ghanshyam Mann]

Mon-Tue/Wed-Fri works as most suitable format. There are always
conflict for many of us but that can be adjusted by working with team
planning.

Another thing can help is to give flexibility to team to have team
topic even on Mon-Tue, which mean team need dedicated room on Mon-Tue
also. For example, if QA want to discuss few of the topic on Mon-Tue
and have Code sprint/Help room etc on rest of week. This can help me
or other QA members to join other team discussion on Wed-Fri. But that
is based on special request and team requirement of number of topics
to discuss.

morning/afternoon format will be little hectic and less productive due
to changing rooms and topic etc, at least for me :)

-gmann


On Mon, Nov 27, 2017 at 7:58 PM, Thierry Carrez  wrote:
> Hi everyone,
>
> We are in the final step in the process of signing the contract with the
> PTG venue. We should be able to announce the location this week !
>
> So it's time to start preparing. We'll have 5 days, like in Denver. One
> thing we'd like to change for this round is to give a bit more
> flexibility in the topics being discussed, especially in the first two days.
>
> In Denver, we selected a number of general "themes" and gave them all a
> room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> project team meeting could get a room for 2 or 3 days on
> Wednesday-Friday. That resulted in a bit of flux during the first two
> days, with a lot of empty rooms as most of the themes did not really
> need 2 days, and a lot of conflicts were present.
>
> For Dublin, the idea would be to still predetermine topics (themes and
> teams) and assign them rooms in advance. But we would be able to assign
> smaller amounts of time (per half-day) based on the expressed needs.
> Beyond those pre-assigned themes/teams we'd add flexibility for other
> groups to book the remaining available rooms in 90-min slots on-demand.
> A bit like how we did reservable rooms in the past, but more integrated
> with the rest of the event. It would all be driven by the PTGbot, which
> would show which topic is being discussed in which room, in addition to
> the current discussion subject within each topic.
>
> We have two options in how we do the split for predetermined topics. We
> used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> general idea there was to allow some people only interested in a team
> meeting to only attend the second part of the week. However most people
> attend all 5 days, and during event feedback some people suggested that
> "themes" should be in the mornings and "teams" in the afternoons (and
> all Friday).
>
> What would be your preference ? The Mon-Tue/Wed-Fri split means less
> room changes, which make it easier on the events team. So all else being
> equal we'd rather keep it the way it is, but I'm open to changing it if
> attendees think it's a good idea.
>
> If you have any other suggestion (that we could implement in the 3
> months we have between now and the event) please let me know :)
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [qa] [patrole] Proposed role switch overhaul to framework

[MONTEIRO, FELIPE C]

Hello Team,

With roughly 3 months left in Queens, we should start to commit to some of the 
Queens goals we discussed during Denver [0]. To that end, [1] sets the 
foundation for streamlining role switching in Patrole.

The current implementation for role switching has many shortcomings:

* Code readability issues (relies on precisely placed call to 
switch_role() in the code, which gets lost amid the rest of the test code)

* Unintuitive user interface (always passing in a Boolean value 
needlessly)

* Not very atomic (there is no convenient "stop button" for the role 
switch; it ends when the test does)

* Needless code coupling between modules

Proposed approach seeks to fix those issues:

* Role switch implemented as context manager to make it obvious "what" 
the role switch affects

* User interface simplified (just call the function, don't worry about 
Boolean value)

* Role switch made as atomic as possible

* De-couples code between modules, resulting in cleaner code

Only downside with proposed approach is - unsurprisingly - code churn.

Any feedback/thoughts/questions are appreciated.

[0] https://etherpad.openstack.org/p/qa-queens-ptg
[1] https://review.openstack.org/#/c/521703/

Thanks,

Felipe

__
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] Ansiblize init-runonce script

[Jeffrey Zhang]

hi

check this [0]. I tried to convert it  to ansible playbooks.

[0] https://review.openstack.org/523072

On Tue, Nov 28, 2017 at 2:57 AM, Ravi Shekhar Jethani 
wrote:

> Hi,
>
> While exploring kolla-ansible I ran into a few issues with
> init-runonce script. This lead to following bugs and patches:
>
> https://launchpad.net/bugs/1732963
> https://review.openstack.org/51
> https://review.openstack.org/521190
>
> But it was highlighted that instead of fixing/changing the
> script, 'ansibilzing' it would be the ideal solution.
> Hence I hereby formally propose the same.
>
> My thoughts:
> * Playbook Name: init-stack.yml
>
> * Playbook path can be:
> kolla-ansible/ansible/init-stack.yml
>
> * The play can be executed like:
> $ kolla-ansible init-stack -i 
>
> * The cirros test image should be downloaded in /tmp
>
> * What should be the behavior if the play is run multiple times
> against the same stack?
>   - some error message OR
>   - simply ignore the action
>
> Kindly provide suggestions.
>
> --
> Best Regards,
> Ravi J.
>
> __
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi Horizon team,


As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
ready, please kindly review it.

http://git.openstack.org/cgit/openstack/heat-dashboard

Also we described points to be clarified in this review, if you find
anything to be noted/fixed, please feel free to put your comment on
this etherpad, we will respond to them.

https://etherpad.openstack.org/p/heat-dashboard-review-point

We are planning to land heat-dashboard in queens-2, hopefully we will
fix any issue until then.

Your cooperation will be highly appreciated.

Regards,
Kaz Shinohara

__
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