Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

2018-10-12 Thread Jay Pipes 

On 10/11/2018 01:08 PM, Zane Bitter wrote:

On 10/10/18 1:35 PM, Jay Pipes wrote:

+tc topic

On 10/10/2018 11:49 AM, Fox, Kevin M wrote:
Sorry. Couldn't quite think of the name. I was meaning, openstack 
project tags.


I think having a tag that indicates the project is no longer using 
SELECT FOR UPDATE (and thus is safe to use multi-writer Galera) is an 
excellent idea, Kevin. ++


I would support such a tag, especially if it came with detailed 
instructions on how to audit your code to make sure you are not doing 
this with sqlalchemy. (Bonus points for a flake8 plugin that can be 
enabled in the gate.)


I can contribute to such a tag's documentation, but I don't currently 
have the bandwidth to start and shepherd it.


(One question for clarification: is this actually _required_ to use 
multi-writer Galera? My previous recollection was that it was possible, 
but inefficient, to use SELECT FOR UPDATE safely as long as you wrote a 
lot of boilerplate to restart the transaction if it failed.)


Certainly not. There is just a higher occurrence of the deadlock error 
in question when using SELECT FOR UPDATE versus using a compare-and-swap 
technique that does things like this:


UPDATE tbl SET field = value, generation = generation + 1
WHERE generation = $expected_generation;

The vast majority of cases I've seen where the deadlock occurred were 
during Rally tests, which were just brute-forcing breakage points and 
not particularly reflecting a real-world usage pattern.


So, in short, yes, it's perfectly safe and fine to use Galera in a 
multi-writer setup from the get-go with most OpenStack projects. It's 
just that *some* OpenStack projects of later releases have fewer code 
areas that aggravate the aforementioned deadlock conditions with Galera 
in multi-writer mode.


Best,
-jay


-jay



From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, October 09, 2018 12:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, 
vault, fabio and FQDN endpoints


On 10/09/2018 03:10 PM, Fox, Kevin M wrote:
Oh, this does raise an interesting question... Should such 
information be reported by the projects up to users through labels? 
Something like, "percona_multimaster=safe" Its really difficult for 
folks to know which projects can and can not be used that way 
currently.


Are you referring to k8s labels/selectors? or are you referring to
project tags (you know, part of that whole Big Tent thing...)?

-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



__ 


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-dev] [goals][upgrade-checkers] Week R-26 Update

2018-10-12 Thread Matt Riedemann 
The big update this week is version 0.1.0 of oslo.upgradecheck was 
released. The documentation along with usage examples can be found here 
[1]. A big thanks to Ben Nemec for getting that done since a few 
projects were waiting for it.


In other updates, some changes were proposed in other projects [2].

And finally, Lance Bragstad and I had a discussion this week [3] about 
the validity of upgrade checks looking for deleted configuration 
options. The main scenario I'm thinking about here is FFU where someone 
is going from Mitaka to Pike. Let's say a config option was deprecated 
in Newton and then removed in Ocata. As the operator is rolling through 
from Mitaka to Pike, they might have missed the deprecation signal in 
Newton and removal in Ocata. Does that mean we should have upgrade 
checks that look at the configuration for deleted options, or options 
where the deprecated alias is removed? My thought is that if things will 
not work once they get to the target release and restart the service 
code, which would definitely impact the upgrade, then checking for those 
scenarios is probably OK. If on the other hand the removed options were 
just tied to functionality that was removed and are otherwise not 
causing any harm then I don't think we need a check for that. It was 
noted that oslo.config has a new validation tool [4] so that would take 
care of some of this same work if run during upgrades. So I think 
whether or not an upgrade check should be looking for config option 
removal ultimately depends on the severity of what happens if the manual 
intervention to handle that removed option is not performed. That's 
pretty broad, but these upgrade checks aren't really set in stone for 
what is applied to them. I'd like to get input from others on this, 
especially operators and if they would find these types of checks useful.


[1] https://docs.openstack.org/oslo.upgradecheck/latest/
[2] https://storyboard.openstack.org/#!/story/2003657
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
[4] 
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html


--

Thanks,

Matt

__
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] [oslo][glance][cinder][nova][keystone] healthcheck

2018-10-12 Thread Morgan Fainberg 
Keystone no longer uses paste (since Rocky) as paste is unmaintained. The
healthcheck app is permanently enabled for keystone at
/healthcheck. We chose to make it a default bit of
functionality in how we have Keystone deployed. We also have unit tests in
place to ensure we don't regress and healthcheck changes behavior down the
line (future releases). You should be able to configure additional bits for
healthcheck in keystone.conf (e.g. detailed mode, disable-by-file, etc).

Cheers,
--Morgan

On Fri, Oct 12, 2018 at 3:07 AM Florian Engelmann <
florian.engelm...@everyware.ch> wrote:

> Hi,
>
> I tried to configure the healthcheck framework (/healthcheck) for nova,
> cinder, glance and keystone but it looks like paste is not used with
> keystone anymore?
>
>
> https://github.com/openstack/keystone/commit/8bf335bb015447448097a5c08b870da8e537a858
>
> In our rocky deployment the healthcheck is working for keystone only and
> I failed to configure it for, eg. nova-api.
>
> Nova seems to use paste?
>
> Is there any example nova api-paste.ini with the olso healthcheck
> middleware enabled? To documentation is hard to understand - at least
> for me.
>
> Thank you for your help.
>
> All the best,
> Florian
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][ci][upgrade] New jobs for tripleo Upgrade in the CI.

2018-10-12 Thread Wesley Hayutin 
On Fri, Oct 12, 2018 at 5:10 AM Sofer Athlan-Guyot 
wrote:

> Hi,
>
> Testing and maintaining a green status for upgrade jobs within the 3h
> time limit has proven to be a very difficult job to say the least.
>

Indeed

>
> The net result has been: we don't have anything even touching the
> upgrade code in the CI.
>
> So during Denver PTG it has been decided to give up on running a full
> upgrade job during the 3h time limit and instead to focus on two
> complementary approach to at least touch the upgrade code:
>  1. run a standalone upgrade: this test the ansible upgrade playbook;
>  2. run a N->N upgrade; this test the upgrade python code;


> And here there are, still not merged but seen working:
>  - tripleo-ci-centos-7-standalone-upgrade:
>https://review.openstack.org/#/c/604706/
>  - tripleo-ci-centos-7-scenario000-multinode-oooq-container-upgrades:
>https://review.openstack.org/#/c/607848/9
>
> The first is good to merge (but other could disagree), the second could
> be as well (but I tend to disagree :))
>
> The first leverage the standalone deployment and execute an standalone
> upgrade just after it.
>
> The limitation is that it only tests non-HA services (sorry pidone,
> cannot test ha in standalone) and only the upgrade_tasks (ie not any
> workflow related to the upgrade cli)
>

This can be augmented with 3rd party.  The pidone team and the ci team are
putting the final touches on a 3rd party job for HA services.  Looking
forward, I could see a 3rd party upgrade job that runs the pidone
verification tests.


>
> The main benefits here are:
>  - ~2h to run the upgrade, still a bit long but far away from the 3h
>time limit;
>  - we trigger a yum upgrade so that we can catch problems there as well;
>  - we test the standalone upgrade which is good in itself;
>  - composable role available (as in standalone/all-in-all deployment) so
>you can make a specific upgrade test for your project if it fits into
>the standalone constraint;
>

These are all huge benefits over the previous implementation that have been
made available to us via the standalone deployment

>
> For this last point, if standalone specific role eventually goes into
> project testing (nova, neutron ...), they could have as well a way to
> test upgrade tasks.  This would be a best case scenario.
>

!   woot !!!
This is a huge point that TripleO folks need to absorb!!
!   woot !!!

In the next several sprints the TripleO CI team will do our best to focus
on the standalone deployments to convert TripleO's upstream jobs over and
paving the way for other projects to start consuming it.  IMHO I would
think other projects would be *very* interested in testing an upgrade of
their individual component w/o all the noise of unrelated
services/components.


>
> Now, for the second point, the N->N upgrade.  Its "limitation" is that
> ... well it doesn't run a yum upgrade at all.  We start from master and
> run the upgrade to master.
>
> It's main benefit are:
>  - it takes ~2h20 to run, so well under the 3h time;
>  - tripleoclient upgrade code is run, which is one thing that the
>standalone ugprade cannot do.
>  - It also tend to exercise idempotency of all the tasks as it runs them
>on an already "upgraded" node;
>  - As added bonus, it could gate the tripleo-upgrade role as well as it
>definitively loads all of the role's tasks[1]
>
> For those that stayed with me to this point, I'm throwing another CI
> test that already proved useful already (caught errors), it's the
> ansible-lint test.  After a standalone deployment we just run
> ansible-lint on all playbook generated[2].
>

This is nice, thanks chem!


>
> It produces standalone_ansible_lint.log[3] in the working directory. It
> only takes a couple of minute to install ansible-lint and run it. It
> definitively gate against typos and the like. It touches hard to
> reach code as well, for instance the fast_forward tasks are linted.
> Still no pidone tasks in there but it could easily be added to a job
> that has HA tasks generated.
>
> Note that by default ansible-lint barks, as the generated playbooks hit
> several lintage problems, so only syntax errors and misnamed tasks or
> parameters are currently activated.  But all the lint problems are
> logged in the above file and can be fixed later on.  At which point we
> could activate full lint gating.
>
> Thanks for this long reading, any comments, shout of victory, cry of
> despair and reviews are welcomed.
>
> [1] but this has still to be investigated.
> [2] testing review https://review.openstack.org/#/c/604756/ and main code
> https://review.openstack.org/#/c/604757/
> [3] sample output http://paste.openstack.org/show/731960/
> --
> Sofer Athlan-Guyot
> chem on #freenode
> Upgrade DFG.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

2018-10-12 Thread Lance Bragstad 
Sending a follow up here quick.

The reviewers actively participating in [0] are nearing a conclusion.
Ultimately, the convention is going to be:

  :[:][:]:[:]

Details about what that actually means can be found in the review [0]. Each
piece is denoted as being required or optional, along with examples. I
think this gives us a pretty good starting place, and the syntax is
flexible enough to support almost every policy naming convention we've
stumbled across.

Now is the time if you have any final input or feedback. Thanks for
sticking with the discussion.

Lance

[0] https://review.openstack.org/#/c/606214/


On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad  wrote:

>
> On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann 
> wrote:
>
>>   On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
>> lbrags...@gmail.com> wrote 
>>  >
>>  > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki 
>> wrote:
>>  > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>>  >   wrote:
>>  >  >
>>  >  > Ideally I would like to see it in the form of least specific to
>> most specific. But more importantly in a way that there is no additional
>> delimiters between the service type and the resource. Finally, I do not
>> like the change of plurality depending on action type.
>>  >  >
>>  >  > I propose we consider
>>  >  >
>>  >  > ::[:]
>>  >  >
>>  >  > Example for keystone (note, action names below are strictly
>> examples I am fine with whatever form those actions take):
>>  >  > identity:projects:create
>>  >  > identity:projects:delete
>>  >  > identity:projects:list
>>  >  > identity:projects:get
>>  >  >
>>  >  > It keeps things simple and consistent when you're looking through
>> overrides / defaults.
>>  >  > --Morgan
>>  >  +1 -- I think the ordering if `resource` comes before
>>  >  `action|subaction` will be more clean.
>>  >
>>  > ++
>>  > These are excellent points. I especially like being able to omit the
>> convention about plurality. Furthermore, I'd like to add that I think we
>> should make the resource singular (e.g., project instead or projects). For
>> example:
>>  > compute:server:list
>>  >
>> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
>> (or confirm-resize)
>>
>> Do we need "action" word there? I think action name itself should convey
>> the operation. IMO below notation without "äction" word looks clear enough.
>> what you say?
>>
>> compute:server:reboot
>> compute:server:confirm_resize
>>
>
> I agree. I simplified this in the current version up for review.
>
>
>>
>> -gmann
>>
>>  >
>>  > Otherwise, someone might mistake compute:servers:get, as "list". This
>> is ultra-nick-picky, but something I thought of when seeing the usage of
>> "get_all" in policy names in favor of "list."
>>  > In summary, the new convention based on the most recent feedback
>> should be:
>>  > ::[:]
>>  > Rules:service-type is always defined in the service types authority
>>  > resources are always singular
>>  > Thanks to all for sticking through this tedious discussion. I
>> appreciate it.
>>  >  /R
>>  >
>>  >  Harry
>>  >  >
>>  >  > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad 
>> wrote:
>>  >  >>
>>  >  >> Bumping this thread again and proposing two conventions based on
>> the discussion here. I propose we decide on one of the two following
>> conventions:
>>  >  >>
>>  >  >> ::
>>  >  >>
>>  >  >> or
>>  >  >>
>>  >  >> :_
>>  >  >>
>>  >  >> Where  is the corresponding service type of the
>> project [0], and  is either create, get, list, update, or delete. I
>> think decoupling the method from the policy name should aid in consistency,
>> regardless of the underlying implementation. The HTTP method specifics can
>> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>>  >  >>
>>  >  >> I think the plurality of the resource should default to what makes
>> sense for the operation being carried out (e.g., list:foobars,
>> create:foobar).
>>  >  >>
>>  >  >> I don't mind the first one because it's clear about what the
>> delimiter is and it doesn't look weird when projects have something like:
>>  >  >>
>>  >  >> :::
>>  >  >>
>>  >  >> If folks are ok with this, I can start working on some
>> documentation that explains the motivation for this. Afterward, we can
>> figure out how we want to track this work.
>>  >  >>
>>  >  >> What color do you want the shed to be?
>>  >  >>
>>  >  >> [0] https://service-types.openstack.org/service-types.json
>>  >  >> [1]
>> https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule
>>  >  >>
>>  >  >> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad <
>> lbrags...@gmail.com> wrote:
>>  >  >>>
>>  >  >>>
>>  >  >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
>> gm...@ghanshyammann.com> wrote:
>>  >  
>>  >     On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
>> j...@johngarbutt.com> wrote 
>>  >    > tl;dr+1 consistent names
>>  >

Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables

2018-10-12 Thread Doug Hellmann 
Sean McGinnis  writes:

> During the Stein PTG in Denver, the release management team talked about ways
> we can make things simpler and reduce the "paper pushing" work that all teams
> need to do right now. One topic that came up was the usefulness of pushing 
> tags
> around milestones during the cycle.
>
> There were a couple of needs identified for doing such "milestone releases":
> 1) It tests the release automation machinery to identify problems before
>the RC and final release crunch time.
> 2) It creates a nice cadence throughout the cycle to help teams stay on
>track and focus on the right things for each phase of the cycle.
> 3) It gives us an indication that teams are healthy, active, and planning
>to include their components in the final release.
>
> One of the big motivators in the past was also to have output that downstream
> distros and users could pick up for testing and early packaging. Based on our
> admittedly anecdotal small sample, it doesn't appear this is actually a big
> need, so we propose to stop tagging milestone releases for the
> cycle-with-milestone projects.

One of the issues that was raised from downstream consumers [1] is that
this complicates upgrade testing using packages, since tools like yum
will think that the stable branch (with a final version tag) has a
higher version number than master (with a dev version computed off of
the first release candidate where the stable branch was created).

We've discussed this problem in the past and not done anything because
the downstream folks were always able to live with the gap until the
first milestone. Now that we're unlikely to have milestone tags for most
projects, the gap will extend to the length of the cycle, blocking
upgrade testing until the release candidates are tagged, shortly before
we're ready to release. They could guess at the next version numbers,
but if they guess wrong they would be left with invalid packages and
have to do a bunch of testing work again. It's better for us to provide
authoritative information about version changes upstream.

We need all projects to increment their version at least by one minor
version at the start of each cycle to save space for patch releases on
the stable branch, so we looked at a few options for triggering that
update automatically.

One option is to add a tag, like an alpha. This is somewhat appealing
because the release team can just do it without anyone on the project
teams having to worry about it. However, I don't particularly like this
option for two reasons. First, the release team would have to monitor
the work in each project and wait for some patch to land after the fork,
so we could tag that (otherwise the branch would get the new version,
too). More importantly, the tag would trigger a release, and I don't
think we want to publish artifacts just to tweak the version
calculation.

A similarly low impact solution is to use pbr's Sem-Ver calculation
feature and inject patches into master to bump the version being
computed by 1 feature level (which should move from x.y.z.0rc1 to
somethinglike x.y+1.0.devN). See [2] for details about how this works.

This is the approach I prefer, and I have a patch to the branching
scripts to add the Sem-Ver instruction to the patches we already
generate to update reno [3].

That change should take care of our transition from Stein->T, but we're
left with versions in Stein that are lower than Rocky right now. So, as
a one time operation, Sean is going to propose empty patches with the
Sem-Ver instruction in the commit message to all of the repositories for
Stein deliverables that have stable/rocky branches.

Let us know if you have any questions.

Doug


[1] 
http://lists.openstack.org/pipermail/openstack-operators/2018-October/015991.html
[2] https://docs.openstack.org/pbr/latest/user/features.html#version 
[3] https://review.openstack.org/#/c/609827/

__
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] [python3] Enabling py37 unit tests

2018-10-12 Thread Corey Bryant 
On Fri, Oct 12, 2018 at 8:59 AM Corey Bryant 
wrote:

>
>
> On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger  wrote:
>
>> On 10/10/2018 23.10, Jeremy Stanley wrote:
>> > I might have only pointed this out on IRC so far, but the
>> > expectation is that testing 3.5 and 3.6 at the same time was merely
>> > transitional since official OpenStack projects should be moving
>> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
>> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
>> > cycle and so will drop 3.5 testing on master in the process.
>>
>> Agreed, this needs some larger communication and explanation on what to
>> do,
>>
>>
> The good news is we now have an initial change underway and successful,
> dropping py35 and enabling py37: https://review.openstack.org/#/c/609557/
>
> I'm happy to get things moving along and start proposing changes like this
> to other projects and communicating with PTLs along the way. Do you think
> we need more discussion/communication on this or should I get started?
>
> Thanks,
> Corey
>

We have a story to track this now at:
https://storyboard.openstack.org/#!/story/2004073

I think we will just get started on proposing changes. I've had a couple of
folks ask if they can help out which is great so we will start to chip away
at the story above. We'll also contact PTLs as we start working on projects
in case they haven't seen this thread.

Of course if anyone objects to us moving forward, please feel free to let
us know.

Thanks,
Corey


>
> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> 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] [goals][python3] week 9 update

2018-10-12 Thread Doug Hellmann 

This is week 9 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html).

== What we learned last week ==

We have claimed a few names on PyPI, and updated a few sdist names where
we couldn't do that. The one remaining project with a rename is heat,
and I'm working on an upgrade script that will clean up the old metadata
to fix the duplicate plugin issue.

* https://review.openstack.org/#/c/606160/

== Ongoing and Completed Work ==

The zuul migration portion of the goal work is completed! Thanks again
to everyone who assisted with creating and reviewing those patches.

We still have quite a few patches with tox settings and for
documentation build updates left open or unreviewed. Those documentation
updates should be relatively quick to review because they're very
minimal patches. Please take a few minutes to look for them and let's
try to get them merged before the first milestone. The tox patches may
require a bit more work to update pylint and the goal champions could
use your help there (see below).

+-+--+-+--+-++---++
| Team| tox defaults | Docs| 3.6 unit | Failing | 
Unreviewed | Total | Champion   |
+-+--+-+--+-++---++
| adjutant|   1/  1  | -   | +|   0 |  
1 | 2 | Doug Hellmann  |
| barbican| +|   1/  3 | +|   1 |  
1 | 7 | Doug Hellmann  |
| blazar  | +| +   | +|   0 |  
0 | 9 | Nguyen Hai |
| Chef OpenStack  | +| -   | -|   0 |  
0 | 2 | Doug Hellmann  |
| cinder  | +| +   | +|   0 |  
0 |11 | Doug Hellmann  |
| cloudkitty  | +| +   | +|   0 |  
0 | 9 | Doug Hellmann  |
| congress|   1/  3  | +   | +|   0 |  
0 | 9 | Nguyen Hai |
| cyborg  | +| +   | +|   0 |  
0 | 7 | Nguyen Hai |
| designate   |   2/  4  | +   | +|   0 |  
1 | 9 | Nguyen Hai |
| Documentation   | +| +   | +|   0 |  
0 |10 | Doug Hellmann  |
| dragonflow  | -| +   | +|   0 |  
0 | 2 | Nguyen Hai |
| ec2-api |   2/  2  | +   | +|   2 |  
2 | 7 ||
| freezer |   1/  5  | +   | +|   0 |  
1 |11 ||
| glance  |   1/  4  | +   | +|   0 |  
0 |10 | Nguyen Hai |
| heat|   3/  8  | +   |   1/  7  |   0 |  
0 |21 | Doug Hellmann  |
| horizon |   1/ 32  | +   | +|   0 |  
1 |34 | Nguyen Hai |
| I18n|   1/  1  | -   | -|   0 |  
0 | 1 | Doug Hellmann  |
| InteropWG   |   3/  4  | +   |   1/  3  |   1 |  
3 |10 | Doug Hellmann  |
| ironic  |   1/ 10  | +   | +|   0 |  
1 |35 | Doug Hellmann  |
| karbor  | +| +   | +|   0 |  
0 | 7 | Nguyen Hai |
| keystone| +| +   | +|   0 |  
0 |18 | Doug Hellmann  |
| kolla   | +| +   | +|   0 |  
0 | 5 ||
| kuryr   | +| +   | +|   0 |  
0 | 9 | Doug Hellmann  |
| magnum  |   2/  5  | +   | +|   0 |  
1 |10 ||
| manila  |   1/  8  | +   | +|   0 |  
0 |13 | Goutham Pacha Ravi |
| masakari|   3/  5  | +   | -|   0 |  
3 | 6 | Nguyen Hai |
| mistral | +| +   | +|   0 |  
0 |13 | Nguyen Hai |
| monasca |   1/ 17  | +   | +|   1 |  
1 |34 | Doug Hellmann  |
| murano  | +| +   | +|   0 |  
0 |14 ||
| neutron |   8/ 18  |   2/ 14 |   2/ 13  |   5 |  
4 |45 | Doug Hellmann  |
| nova| +| +   | +|   0 |  
0 |14 ||
| octavia | +| +   | +|   0 |

Re: [openstack-dev] [python3] Enabling py37 unit tests

2018-10-12 Thread Corey Bryant 
On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger  wrote:

> On 10/10/2018 23.10, Jeremy Stanley wrote:
> > I might have only pointed this out on IRC so far, but the
> > expectation is that testing 3.5 and 3.6 at the same time was merely
> > transitional since official OpenStack projects should be moving
> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> > cycle and so will drop 3.5 testing on master in the process.
>
> Agreed, this needs some larger communication and explanation on what to do,
>
>
The good news is we now have an initial change underway and successful,
dropping py35 and enabling py37: https://review.openstack.org/#/c/609557/

I'm happy to get things moving along and start proposing changes like this
to other projects and communicating with PTLs along the way. Do you think
we need more discussion/communication on this or should I get started?

Thanks,
Corey


Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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] [python3] Enabling py37 unit tests

2018-10-12 Thread Corey Bryant 
On Wed, Oct 10, 2018 at 7:36 PM Goutham Pacha Ravi 
wrote:

> On Wed, Oct 10, 2018 at 2:10 PM Jeremy Stanley  wrote:
> >
> > On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote:
> > [...]
> > > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and
> > > 3.7.
> > [...]
> >
> > I might have only pointed this out on IRC so far, but the
> > expectation is that testing 3.5 and 3.6 at the same time was merely
> > transitional since official OpenStack projects should be moving
> > their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
> > Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
> > cycle and so will drop 3.5 testing on master in the process.
>
> ++ on switching python3.5 jobs to testing with python3.7 on Bionic.
> python3.5 wasn't supported on all distros [1][2][3][4][5]. Xenial had it,
> so it was nice to test with it when developing Queens and Rocky.
>
>
> Thanks Corey for starting this effort. I proposed changes to
> manila repos to use your template [1] [2], but the interpreter's not
> being installed,
> do you need to make any bindep changes to enable the "universe" ppa and
> install
> python3.7 and python3.7-dev?
>

Following up on this for anyone else who's following along. The python3.7
interpreter and development files are now correctly being installed after
some additional changes in zuul jobs. And we have our first py37 SUCCESS!
https://review.openstack.org/#/c/609557/

Goutham, thanks again for jumping in and adding py37 tests to your projects.

Thanks,
Corey


>
> [1] OpenSuse https://software.opensuse.org/package/python3
> [2] Ubuntu https://packages.ubuntu.com/search?keywords=python3
> [3] Fedora https://apps.fedoraproject.org/packages/python3
> [4] Arch https://www.archlinux.org/packages/extra/x86_64/python/
> [5] Gentoo https://wiki.gentoo.org/wiki/Project:Python/Implementations
> [6] manila https://review.openstack.org/#/c/609558
> [7] python-manilaclient https://review.openstack.org/609557
>
> --
> Goutham
>
> > --
> > Jeremy Stanley
> >
> __
> > 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] [tc] assigning new liaisons to projects

2018-10-12 Thread Doug Hellmann 
Trinh Nguyen  writes:

> Thank Doug for coordinating this,
>
> Is there any way for us to update the health of the Searchlight project to
> reflect the current state? Right now the status is not good to attract new
> contributors.

When the new liaisons are assigned, please talk to them about the
current status.

Doug

>
> Bests,
>
> On Fri, Oct 12, 2018 at 6:50 AM Doug Hellmann  wrote:
>
>> Doug Hellmann  writes:
>>
>> > TC members,
>> >
>> > Since we are starting a new term, and have several new members, we need
>> > to decide how we want to rotate the liaisons attached to each our
>> > project teams, SIGs, and working groups [1].
>> >
>> > Last term we went through a period of volunteer sign-up and then I
>> > randomly assigned folks to slots to fill out the roster evenly. During
>> > the retrospective we talked a bit about how to ensure we had an
>> > objective perspective for each team by not having PTLs sign up for their
>> > own teams, but I don't think we settled on that as a hard rule.
>> >
>> > I think the easiest and fairest (to new members) way to manage the list
>> > will be to wipe it and follow the same process we did last time. If you
>> > agree, I will update the page this week and we can start collecting
>> > volunteers over the next week or so.
>> >
>> > Doug
>> >
>> > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>> >
>> >
>> __
>> > 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
>>
>> I have cleared out the old assignments. Please go over and edit the wiki
>> page to add yourself to the teams you want to volunteer for. Remember
>> that each member needs to sign up for exactly 10 teams. If you don't
>> volunteer for 10, we'll use the script to make random assignments for
>> the remaining slots.
>>
>> 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
>>
>
>
> -- 
> *Trinh Nguyen*
> *www.edlab.xyz *
> __
> 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-operators] [SIGS] Ops Tools SIG

2018-10-12 Thread Sean McGinnis 
On Fri, Oct 12, 2018 at 11:25:20AM +0200, Martin Magr wrote:
> Greetings guys,
> 
> On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
> 
> > Adding the mailing lists back to your reply, thank you :)
> >
> > I guess that +melvin.hills...@huawei.com  can
> > help us a little bit organizing the SIG,
> > but I guess the first thing would be collecting a list of tools which
> > could be published
> > under the umbrella of the SIG, starting by the ones already in Osops.
> >
> > Publishing documentation for those tools, and the catalog under
> > docs.openstack.org
> > is possibly the next step (or a parallel step).
> >
> >
> > On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister 
> > wrote:
> >
> >> Hi Miguel,
> >>
> >> I would love to join this. What do I need to do?
> >>
> >> Sent from my iPhone
> >>
> >> On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo 
> >> wrote:
> >>
> >> Hello
> >>
> >> Yesterday, during the Oslo meeting we discussed [6] the possibility
> >> of creating a new Special Interest Group [1][2] to provide home and release
> >> means for operator related tools [3] [4] [5]
> >>
> >>
>   all of those tools have python dependencies related to openstack such as
> python-openstackclient or python-pbr. Which is exactly the reason why we
> moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG to
> Cloud SIG. AFAIR we had some issues of having opstools SIG being dependent
> on openstack SIG. I believe that Cloud SIG is proper home for tools like
> [3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains
> general tools like fluentd, sensu, collectd.
> 
> 
> Hope this helps,
> Martin
> 

Hey Martin,

I'm not sure I understand the issue with these tools have dependencies on other
packages and the relationship to SIG ownership. Is your concern (or the history
of a concern you are pointing out) that the tools would have a more difficult
time if they required updates to dependencies if they are owned by a different
group?

Thanks!
Sean

__
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] Stepping down as core

2018-10-12 Thread Dmitry Tantsur 
I'm sad to hear it :( Good luck, do not disappear completely, it was a pleasure 
to work with you. See you in Berlin!


On 10/11/18 1:40 PM, Sam Betts (sambetts) wrote:
As many of you will have seen on IRC, I've mostly been appearing AFK for the 
last couple of development cycles. Due to other tasks downstream most of my 
attention has been drawn away from upstream Ironic development. Going forward 
I'm unlikely to be as heavily involved with the Ironic project as I have been in 
the past, so I am stepping down as a core contributor to make way for those more 
involved and with more time to contribute.


That said I do not intend to disappear, Myself and my colleagues plan to 
continue to support the Cisco Ironic drivers, we just won't be so heavily 
involved in core ironic development and its worth noting that although I might 
appear AFK on IRC because my main focus is on other things, I always have an ear 
to the ground and direct pings will generally reach me.


I will be in Berlin for the OpenStack summit, so to those that are attending I 
hope to see you there.


The Ironic project has been (and I hope continues to be) an awesome place to 
contribute too, thank you


Sam Betts
sambetts


__
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] [tripleo][ci][upgrade] New jobs for tripleo Upgrade in the CI.

2018-10-12 Thread Sofer Athlan-Guyot 
Hi,

Testing and maintaining a green status for upgrade jobs within the 3h
time limit has proven to be a very difficult job to say the least.

The net result has been: we don't have anything even touching the
upgrade code in the CI.

So during Denver PTG it has been decided to give up on running a full
upgrade job during the 3h time limit and instead to focus on two
complementary approach to at least touch the upgrade code:
 1. run a standalone upgrade: this test the ansible upgrade playbook;
 2. run a N->N upgrade; this test the upgrade python code;

And here there are, still not merged but seen working:
 - tripleo-ci-centos-7-standalone-upgrade:
   https://review.openstack.org/#/c/604706/
 - tripleo-ci-centos-7-scenario000-multinode-oooq-container-upgrades:
   https://review.openstack.org/#/c/607848/9

The first is good to merge (but other could disagree), the second could
be as well (but I tend to disagree :))

The first leverage the standalone deployment and execute an standalone
upgrade just after it.

The limitation is that it only tests non-HA services (sorry pidone,
cannot test ha in standalone) and only the upgrade_tasks (ie not any
workflow related to the upgrade cli)

The main benefits here are:
 - ~2h to run the upgrade, still a bit long but far away from the 3h
   time limit;
 - we trigger a yum upgrade so that we can catch problems there as well;
 - we test the standalone upgrade which is good in itself;
 - composable role available (as in standalone/all-in-all deployment) so
   you can make a specific upgrade test for your project if it fits into
   the standalone constraint;

For this last point, if standalone specific role eventually goes into
project testing (nova, neutron ...), they could have as well a way to
test upgrade tasks.  This would be a best case scenario.

Now, for the second point, the N->N upgrade.  Its "limitation" is that
... well it doesn't run a yum upgrade at all.  We start from master and
run the upgrade to master.

It's main benefit are:
 - it takes ~2h20 to run, so well under the 3h time;
 - tripleoclient upgrade code is run, which is one thing that the
   standalone ugprade cannot do.
 - It also tend to exercise idempotency of all the tasks as it runs them
   on an already "upgraded" node;
 - As added bonus, it could gate the tripleo-upgrade role as well as it
   definitively loads all of the role's tasks[1]

For those that stayed with me to this point, I'm throwing another CI
test that already proved useful already (caught errors), it's the
ansible-lint test.  After a standalone deployment we just run
ansible-lint on all playbook generated[2].

It produces standalone_ansible_lint.log[3] in the working directory. It
only takes a couple of minute to install ansible-lint and run it. It
definitively gate against typos and the like. It touches hard to
reach code as well, for instance the fast_forward tasks are linted.
Still no pidone tasks in there but it could easily be added to a job
that has HA tasks generated.

Note that by default ansible-lint barks, as the generated playbooks hit
several lintage problems, so only syntax errors and misnamed tasks or
parameters are currently activated.  But all the lint problems are
logged in the above file and can be fixed later on.  At which point we
could activate full lint gating.

Thanks for this long reading, any comments, shout of victory, cry of
despair and reviews are welcomed.

[1] but this has still to be investigated.
[2] testing review https://review.openstack.org/#/c/604756/ and main code 
https://review.openstack.org/#/c/604757/
[3] sample output http://paste.openstack.org/show/731960/
--
Sofer Athlan-Guyot
chem on #freenode
Upgrade DFG.

__
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] [kayobe][kolla] Announcing the release of Kayobe 4.0.0

2018-10-12 Thread Mark Goddard 
Hi,

Announcing the release of Kayobe 4.0.0. This release includes support for
the Queens release of OpenStack, and is the first release of Kayobe built
using the OpenStack infrastructure.

Release notes:
https://kayobe-release-notes.readthedocs.io/en/latest/queens.html#relnotes-4-0-0-stable-queens
Documentation: https://kayobe.readthedocs.io

Thanks to everyone who contributed to this release!

Looking forward, we intend to catch up with the OpenStack release cycle, by
making a smaller release with support for OpenStack Rocky, then moving
straight onto Stein.

Cheers,
Mark
__
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] [oslo][glance][cinder][nova][keystone] healthcheck

2018-10-12 Thread Florian Engelmann 

Hi,

I tried to configure the healthcheck framework (/healthcheck) for nova, 
cinder, glance and keystone but it looks like paste is not used with 
keystone anymore?


https://github.com/openstack/keystone/commit/8bf335bb015447448097a5c08b870da8e537a858

In our rocky deployment the healthcheck is working for keystone only and 
I failed to configure it for, eg. nova-api.


Nova seems to use paste?

Is there any example nova api-paste.ini with the olso healthcheck 
middleware enabled? To documentation is hard to understand - at least 
for me.


Thank you for your help.

All the best,
Florian


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

Re: [openstack-dev] [Openstack-operators] [SIGS] Ops Tools SIG

2018-10-12 Thread Martin Magr 
Greetings guys,

On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> Adding the mailing lists back to your reply, thank you :)
>
> I guess that +melvin.hills...@huawei.com  can
> help us a little bit organizing the SIG,
> but I guess the first thing would be collecting a list of tools which
> could be published
> under the umbrella of the SIG, starting by the ones already in Osops.
>
> Publishing documentation for those tools, and the catalog under
> docs.openstack.org
> is possibly the next step (or a parallel step).
>
>
> On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister 
> wrote:
>
>> Hi Miguel,
>>
>> I would love to join this. What do I need to do?
>>
>> Sent from my iPhone
>>
>> On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo 
>> wrote:
>>
>> Hello
>>
>> Yesterday, during the Oslo meeting we discussed [6] the possibility
>> of creating a new Special Interest Group [1][2] to provide home and release
>> means for operator related tools [3] [4] [5]
>>
>>
  all of those tools have python dependencies related to openstack such as
python-openstackclient or python-pbr. Which is exactly the reason why we
moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG to
Cloud SIG. AFAIR we had some issues of having opstools SIG being dependent
on openstack SIG. I believe that Cloud SIG is proper home for tools like
[3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains
general tools like fluentd, sensu, collectd.


Hope this helps,
Martin


>
>> I continued the discussion with M.Hillsman later, and he made me
>> aware of the operator working group and mailing list, which existed even
>> before the SIGs.
>>
>> I believe it could be a very good idea, to give life and more
>> visibility to all those very useful tools (for example, I didn't know some
>> of them existed ...).
>>
>>Give this, I have two questions:
>>
>>1) Do you know or more tools which could find home under an Ops Tools
>> SIG umbrella?
>>
>>2) Do you want to join us?
>>
>>
>> Best regards and have a great day.
>>
>>
>> [1] https://governance.openstack.org/sigs/
>> [2] http://git.openstack.org/cgit/openstack/governance-
>> sigs/tree/sigs.yaml
>> [3] https://wiki.openstack.org/wiki/Osops
>> [4] http://git.openstack.org/cgit/openstack/ospurge/tree/
>> [5] http://git.openstack.org/cgit/openstack/os-log-merger/tree/
>> [6] http://eavesdrop.openstack.org/meetings/oslo/
>> 2018/oslo.2018-10-08-15.00.log.html#l-130
>>
>>
>>
>> --
>> Miguel Ángel Ajo
>> OSP / Networking DFG, OVN Squad Engineering
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> --
> Miguel Ángel Ajo
> OSP / Networking DFG, OVN Squad Engineering
>
> __
> 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
>
>


-- 
Martin Mágr
Senior Software Engineer
Red Hat Czech
__
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] [cinder][swift] FOSDEM Call for Participation: Software Defined Storage devroom

2018-10-12 Thread Niels de Vos 
CfP for the Software Defined Storage devroom at FOSDEM 2019 (Brussels,
Belgium, February 3rd).

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renown for being
highly developer- oriented and brings together 8000+ participants from
all over the world.  It is held in the city of Brussels (Belgium).

FOSDEM 2019 will take place during the weekend of February 2nd-3rd 2019.
More details about the event can be found at http://fosdem.org/

** Call For Participation

The Software Defined Storage devroom will go into it's third round for
talks around Open Source Software Defined Storage projects, management
tools and real world deployments.

Presentation topics could include but are not limited too:

- Your work on a SDS project like Ceph, Gluster, OpenEBS or LizardFS

- Your work on or with SDS related projects like SWIFT or Container
  Storage Interface

- Management tools for SDS deployments

- Monitoring tools for SDS clusters

** Important dates:

- Nov 25th 2018:  submission deadline for talk proposals
- Dec 17th 2018:  announcement of the final schedule
- Feb  3rd 2019:  Software Defined Storage dev room

Talk proposals will be reviewed by a steering committee:
- Niels de Vos (Gluster Developer - Red Hat)
- Jan Fajerski (Ceph Developer - SUSE)
- other volunteers TBA

Use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM19

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have already
  created it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab) and Bio
  ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Software Defined Storage devroom" track (on the
  "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the intended
  audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

- Provide an expected length of your talk in the "Duration" field. Please
  count at least 10 minutes of discussion into your proposal plus allow
  5 minutes for the handover to the next presenter.
  Suggested talk length would be 20+10 and 45+15 minutes.

** Recording of talks

The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people can
watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed. If you plan to be a
speaker, please understand that by doing so you implicitly give consent
for your talk to be recorded and streamed. The recordings will be
published under the same license as all FOSDEM content (CC-BY).

Hope to hear from you soon! And please forward this announcement.

If you have any further questions, please write to the mailinglist at
storage-devr...@lists.fosdem.org and we will try to answer as soon as
possible.

Thanks!

__
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] [taas] rocky

2018-10-12 Thread Takashi Yamamoto 
i've just created 4.0.0 and rocky branch.


On Wed, Sep 26, 2018 at 6:55 PM Takashi Yamamoto  wrote:
>
> hi,
>
> it seems we forgot to create rocky branch.
> i'll make a release and the branch sooner or later, unless someone
> beat me to do so.

__
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