Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read

[Emilien Macchi]

https://review.openstack.org/575264 just landed (and didn't timeout in
check nor gate without recheck, so good sigh it helped to mitigate).

I've restore and rechecked some patches that I evacuated from the gate,
please do not restore others or recheck or approve anything for now, and
see how it goes with a few patches.
We're still working with Steve on his patches to optimize the way we deploy
containers on the registry and are investigating how we could make it
faster with a proxy.

Stay tuned and thanks for your patience.

On Wed, Jun 13, 2018 at 5:50 PM, Emilien Macchi  wrote:

> TL;DR: gate queue was 25h+, we put all patches from gate on standby, do
> not restore/recheck until further announcement.
>
> We recently enabled the containerized undercloud for multinode jobs and we
> believe this was a bit premature as the container download process wasn't
> optimized so it's not pulling the mirrors for the same containers multiple
> times yet.
> It caused the job runtime to increase and probably the load on docker.io
> mirrors hosted by OpenStack Infra to be a bit slower to provide the same
> containers multiple times. The time taken to prepare containers on the
> undercloud and then for the overcloud caused the jobs to randomly timeout
> therefore the gate to fail in a high amount of times, so we decided to
> remove all jobs from the gate by abandoning the patches temporarily (I have
> them in my browser and will restore when things are stable again, please do
> not touch anything).
>
> Steve Baker has been working on a series of patches that optimize the way
> we prepare the containers but basically the workflow will be:
> - pull containers needed for the undercloud into a local registry, using
> infra mirror if available
> - deploy the containerized undercloud
> - pull containers needed for the overcloud minus the ones already pulled
> for the undercloud, using infra mirror if available
> - update containers on the overcloud
> - deploy the containerized undercloud
>
> With that process, we hope to reduce the runtime of the deployment and
> therefore reduce the timeouts in the gate.
> To enable it, we need to land in that order: https://review.
> openstack.org/#/c/571613/, https://review.openstack.org/#/c/574485/,
> https://review.openstack.org/#/c/571631/ and https://review.openstack.
> org/#/c/568403.
>
> In the meantime, we are disabling the containerized undercloud recently
> enabled on all scenarios: https://review.openstack.org/#/c/575264/ for
> mitigation with the hope to stabilize things until Steve's patches land.
> Hopefully, we can merge Steve's work tonight/tomorrow and re-enable the
> containerized undercloud on scenarios after checking that we don't have
> timeouts and reasonable deployment runtimes.
>
> That's the plan we came with, if you have any question / feedback please
> share it.
> --
> Emilien, Steve and Wes
>



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

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

[Saravanan KR]

+1

Regards,
Saravanan KR

On Wed, Jun 13, 2018 at 9:20 PM, Emilien Macchi  wrote:
> Alan Bishop has been highly involved in the Storage backends integration in
> TripleO and Puppet modules, always here to update with new features, fix
> (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
>
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
>
> Please vote -1/+1,
> Thanks!
> --
> 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

Re: [openstack-dev] [requirements][daisycloud][freezer][fuel][tatu][trove] pycrypto is dead andinsecure, you should migrate

[Matthew Thode]

On 18-06-14 01:28:14, Zhang Fan wrote:
> Hi, Matthew
> 
> 
> Sorry for the late updates on patches. Trove team members recently are sort 
> of busy with daily work. And it takes me awhile to get back focusing the 
> upstream. Fortunately, we are still there, and trove is still alive :)
> 
> 
> About removing pycryto dependency, there are two patches, as [0] is merged 
> and [1] is on the way, thanks Zhao Chao for working on [0]:
> 
> 
> [0].https://review.openstack.org/#/c/560292/
> 
> [1].https://review.openstack.org/#/c/573070/
> 
> Thanks anyone who helps us on this improments and looks forward to have more 
> contributors joining us in OpenStack/Trove !
> 
> 
> Best wishes.
> Fan Zhang
> 
>  Original Message
> Sender: Matthew Thode
> Recipient: 
> openstack-dev@lists.openstack.org
> Date: Wednesday, Jun 13, 2018 23:23
> Subject: Re: 
> [openstack-dev][requirements][daisycloud][freezer][fuel][tatu][trove] 
> pycrypto is dead andinsecure, you should migrate
> 
> 
> On 18-06-13 20:53:06, Rong Zhu wrote:
> > Hi, Matthew
> >
> > Solum removed pycryto dependency in [0]
> >
> > [0]: https://review.openstack.org/#/c/574244/
> >
> > --
> > Thanks,
> > Rong Zhu
> 
> Yep, just in time for the next reminder email too :D
> 
> > ++-+--+---+
> > | Repository | Filename 
> >| Line | Text
> >   |
> > ++-+--+---+
> > | daisycloud-core| code/daisy/requirements.txt  
> >|   17 | pycrypto>=2.6 # Public Domain   
> >   |
> > | freezer| requirements.txt 
> >|   21 | pycrypto>=2.6 # Public Domain   
> >   |
> > | fuel-dev-tools | 
> > contrib/fuel-setup/requirements.txt |5 
> > | pycrypto==2.6.1   |
> > | fuel-web   | nailgun/requirements.txt 
> >|   24 | pycrypto>=2.6.1 
> >   |
> > | tatu   | requirements.txt 
> >|7 | pycrypto>=2.6.1 
> >   |
> > | tatu   | test-requirements.txt
> >|7 | pycrypto>=2.6.1 
> >   |
> > | trove  | 
> > integration/scripts/files/requirements/fedora-requirements.txt  |   30 
> > | pycrypto>=2.6  # Public Domain|
> > | trove  | 
> > integration/scripts/files/requirements/ubuntu-requirements.txt  |   29 
> > | pycrypto>=2.6  # Public Domain|
> > | trove  | requirements.txt 
> >|   47 | pycrypto>=2.6 # Public Domain   
> >   |
> > ++-+--+---+
> 
> Reverse order this time :D
> 
> trove has https://review.openstack.org/#/c/573070 which is making good
> progress
> 
> The rest (tatu, fuel, freezer, daisycloud-core) I don't see any reviews,
> starting to wonder if they watch the list.
> 

Thanks for the work on it :D

On a related note I've created https://review.openstack.org/575163 for
freezer (depends on Doug's work though).

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [tripleo] zuul change gating repo name change

[Wesley Hayutin]

Greetings,

Please be aware the yum repo created in tripleo ci jobs is going to change
names to include the release [1].  This is done to ensure that only the
appropriate patches are installed when patches from multiple branches are
in play.  This is especially important to upgrade jobs.

If you are working on a patch that uses the gating.repo, this patch [1]
will impact your work.

Thank you!!

[1] https://review.openstack.org/#/c/572736/
__
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] [requirements][daisycloud][freezer][fuel][tatu][trove] pycrypto is dead andinsecure, you should migrate

[Zhang Fan]

Hi, Matthew


Sorry for the late updates on patches. Trove team members recently are sort of 
busy with daily work. And it takes me awhile to get back focusing the upstream. 
Fortunately, we are still there, and trove is still alive :)


About removing pycryto dependency, there are two patches, as [0] is merged and 
[1] is on the way, thanks Zhao Chao for working on [0]:


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

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

Thanks anyone who helps us on this improments and looks forward to have more 
contributors joining us in OpenStack/Trove !


Best wishes.
Fan Zhang

 Original Message
Sender: Matthew Thode
Recipient: openstack-dev@lists.openstack.org
Date: Wednesday, Jun 13, 2018 23:23
Subject: Re: 
[openstack-dev][requirements][daisycloud][freezer][fuel][tatu][trove] pycrypto 
is dead andinsecure, you should migrate


On 18-06-13 20:53:06, Rong Zhu wrote:
> Hi, Matthew
>
> Solum removed pycryto dependency in [0]
>
> [0]: https://review.openstack.org/#/c/574244/
>
> --
> Thanks,
> Rong Zhu

Yep, just in time for the next reminder email too :D

> ++-+--+---+
> | Repository | Filename   
>  | Line | Text
>   |
> ++-+--+---+
> | daisycloud-core| code/daisy/requirements.txt
>  |   17 | pycrypto>=2.6 # Public Domain   
>   |
> | freezer| requirements.txt   
>  |   21 | pycrypto>=2.6 # Public Domain   
>   |
> | fuel-dev-tools | 
> contrib/fuel-setup/requirements.txt |5 | 
> pycrypto==2.6.1   |
> | fuel-web   | nailgun/requirements.txt   
>  |   24 | pycrypto>=2.6.1 
>   |
> | tatu   | requirements.txt   
>  |7 | pycrypto>=2.6.1 
>   |
> | tatu   | test-requirements.txt  
>  |7 | pycrypto>=2.6.1 
>   |
> | trove  | 
> integration/scripts/files/requirements/fedora-requirements.txt  |   30 | 
> pycrypto>=2.6  # Public Domain|
> | trove  | 
> integration/scripts/files/requirements/ubuntu-requirements.txt  |   29 | 
> pycrypto>=2.6  # Public Domain|
> | trove  | requirements.txt   
>  |   47 | pycrypto>=2.6 # Public Domain   
>   |
> ++-+--+---+

Reverse order this time :D

trove has https://review.openstack.org/#/c/573070 which is making good
progress

The rest (tatu, fuel, freezer, daisycloud-core) I don't see any reviews,
starting to wonder if they watch the list.

--
Matthew Thode (prometheanfire)


__
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] tripleo gate is blocked - please read

[Emilien Macchi]

TL;DR: gate queue was 25h+, we put all patches from gate on standby, do not
restore/recheck until further announcement.

We recently enabled the containerized undercloud for multinode jobs and we
believe this was a bit premature as the container download process wasn't
optimized so it's not pulling the mirrors for the same containers multiple
times yet.
It caused the job runtime to increase and probably the load on docker.io
mirrors hosted by OpenStack Infra to be a bit slower to provide the same
containers multiple times. The time taken to prepare containers on the
undercloud and then for the overcloud caused the jobs to randomly timeout
therefore the gate to fail in a high amount of times, so we decided to
remove all jobs from the gate by abandoning the patches temporarily (I have
them in my browser and will restore when things are stable again, please do
not touch anything).

Steve Baker has been working on a series of patches that optimize the way
we prepare the containers but basically the workflow will be:
- pull containers needed for the undercloud into a local registry, using
infra mirror if available
- deploy the containerized undercloud
- pull containers needed for the overcloud minus the ones already pulled
for the undercloud, using infra mirror if available
- update containers on the overcloud
- deploy the containerized undercloud

With that process, we hope to reduce the runtime of the deployment and
therefore reduce the timeouts in the gate.
To enable it, we need to land in that order:
https://review.openstack.org/#/c/571613/,
https://review.openstack.org/#/c/574485/,
https://review.openstack.org/#/c/571631/ and
https://review.openstack.org/#/c/568403.

In the meantime, we are disabling the containerized undercloud recently
enabled on all scenarios: https://review.openstack.org/#/c/575264/ for
mitigation with the hope to stabilize things until Steve's patches land.
Hopefully, we can merge Steve's work tonight/tomorrow and re-enable the
containerized undercloud on scenarios after checking that we don't have
timeouts and reasonable deployment runtimes.

That's the plan we came with, if you have any question / feedback please
share it.
-- 
Emilien, Steve and Wes
__
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] [tap-as-a-service] core reviewer update

[SUZUKI, Kazuhiro]

Hi,

Thank you.
I'm glad to be able to support the TaaS community.

Regards,
Kaz

From: Takashi Yamamoto 
Subject: Re: [openstack-dev] [tap-as-a-service] core reviewer update
Date: Wed, 13 Jun 2018 16:34:09 +0900

> i just made the change as i haven't got any concerns.
> welcome, kaz!
> 
> On Thu, May 31, 2018 at 2:36 PM, Takashi Yamamoto  
> wrote:
>> hi,
>>
>> i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
>> he is one of active members of the project.
>> he is also the original author of tap-as-a-service-dashboard.
>> i'll make the change after a week unless i hear any objections/concerns.
>>
>> [1] https://review.openstack.org/#/admin/groups/957,members
>> http://stackalytics.com/report/contribution/tap-as-a-service/120
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [nova] nova-cells-v1 intermittent gate failure

[melanie witt]

Hi everybody,

Just a heads up that we have an intermittent gate failure of the 
nova-cells-v1 job happening right now [1] and a revert of the tempest 
change related to it has been approved [2] and will be making its way 
through the gate. The nova-cells-v1 job will be failing until [2] merges.


-melanie

[1] https://bugs.launchpad.net/nova/+bug/1776684
[2] https://review.openstack.org/575132

__
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] [cinder] Enabling tempest test for in-use volume extending

[Matt Riedemann]

On 6/7/2018 8:33 AM, Lucio Seki wrote:

Since Pike release, Cinder supports in-use volume extending [1].
By default, it assumes that every storage backend is able to perform 
this operation.


Actually, by default, Tempest assumes that no backends support it, which 
is why it's disabled by default in Tempest:


https://review.openstack.org/#/c/480746/7/tempest/config.py

And then only enabled by default in devstack if you're using lvm and 
libvirt since at the time those were the only backends that supported it.


Thus, the tempest test for this feature should be enabled by default. A 
patch was submitted to enable it [2].


Please note that, after this patch being merged, the 3rd party CI 
maintainers may need to override this configuration, if the backend 
being tested does not support in-use volume extending.


[1] Add ability to extend 'in-use' volume: 
https://review.openstack.org/#/c/454287/
[2] Enable tempest tests for attached volume extending: 
https://review.openstack.org/#/c/572188


--

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] [nova] review runways check-in and feedback

[Matt Riedemann]

On 6/13/2018 3:33 PM, melanie witt wrote:


We've been experimenting with a new process this cycle, Review Runways 
[1] and we're about at the middle of the cycle now as we had the r-2 
milestone last week June 7.


I wanted to start a thread and gather thoughts and feedback from the 
nova community about how they think runways have been working or not 
working and lend any suggestions to change or improve as we continue on 
in the rocky cycle.


We decided to try the runways process to increase the chances of core 
reviewers converging on the same changes and thus increasing reviews and 
merges on approved blueprint work. As of today, we have 69 blueprints 
approved and 28 blueprints completed, we just passed r-2 June 7 and r-3 
is July 26 and rc1 is August 9 [2].


Do people feel like they've been receiving more review on their 
blueprints? Does it seem like we're completing more blueprints earlier? 
Is there feedback or suggestions for change that you can share?


Lots of cores are not reviewing stuff in the current runways slots, 
which defeats the purpose of runways for the most part if the majority 
of the core team aren't going to review what's in a slot.


Lots of people have ready-for-runways blueprint series that aren't 
queued up in the runways etherpad, and then ask for reviews on those 
series and I have to tell them, "throw it in the runways queue".


I'm not sure if people are thinking subteams need to review series that 
are ready for wider review first, but especially for the placement 
stuff, I think those things need to be slotted up if they are ready. 
Just because it's in the queue doesn't mean interested parties can't 
review it. I've seen things in queue get merged before they hit a slot, 
and that's fine.


I personally would also like to see stuff in the queue so I can get a 
better idea of what is being worked on and what's ready, especially as 
we wind down into the 3rd milestone and we're going to start crunching 
for major deliverables that aren't yet done. Speaking just for myself, 
I've got a bit of anxiety going on right now because I have a feeling we 
have several major efforts that still need to get done for Rocky and 
they aren't getting the proper focus from the majority of the team (the 
nested resource provider migration stuff and handling a down cell are 
the major ones on my list).


Having said that, it's clear from the list of things in the runways 
etherpad that there are some lower priority efforts that have been 
completed probably because they leveraged runways (there are a few 
xenapi blueprints for example, and the powervm driver changes).


--

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] [qa][python3] advice needed with updating lib-forward-testing jobs

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-13 12:19:18 -0400:
> Excerpts from Doug Hellmann's message of 2018-06-13 10:31:00 -0400:
> > Excerpts from Ghanshyam's message of 2018-06-13 16:52:33 +0900:
> > >   On Wed, 13 Jun 2018 05:09:03 +0900 Doug Hellmann 
> > >  wrote  
> > >  > I would like to create a version of the jobs that run as part of
> > >  > lib-forward-testing (legacy-tempest-dsvm-neutron-src) that works under
> > >  > python 3. I'm not sure the best way to proceed, since that's a legacy
> > >  > job.
> > >  > 
> > >  > I'm not sure I'm familiar enough with the job to port it to be
> > >  > zuulv3 native and allow us to drop the "legacy". Should I just
> > >  > duplicate that job and modify it and keep the new one as "legacy"
> > >  > too?
> > >  > 
> > >  > Is there a different job I should base the work on? I don't see 
> > > anything
> > >  > obvious in the tempest repo's .zuul.yaml file.
> > > 
> > > I had a quick glance of this job (legacy-tempest-dsvm-neutron-src) and it 
> > > is similar to tempest-full-py3 job except it override the LIBS_FROM_GIT 
> > > with corresponding lib. tempest-full-py3 job is py3 based with 
> > > tempest-full tests running and disable the swift services 
> > > 
> > > You can create a new job (something tempest-full-py3-src) derived from 
> > > 'tempest-full-py3' if all set var is ok for you like disable swift OR 
> > > derived  'devstack-tempest' and then build other var similar to 
> > > 'tempest-full-py3'.  Extra things you need to do is to add libs you want 
> > > to override in 'required_project' list (FYI- 
> > > Now LIBS_FROM_GIT is automatically set based on required projects [2]) .
> > > 
> > > Later, old job (legacy-tempest-dsvm-neutron-src) can be migrated 
> > > separately if needed to run or removed. 
> > > 
> > > But I am not sure which repo  should own this new job.
> > 
> > Could it be as simple as adding tempest-full-py3 with the
> > required-projects list updated to include the current repository? So
> > there isn't a special separate job, and we would just reuse
> > tempest-full-py3 for this?
> > 
> > It would be less "automatic" than the current project-template and job,
> > but still relatively simple to set up. Am I missing something? This
> > feels too easy...
> 
> I think I could define a job with a name like tempest-full-py3-src based
> on tempest-full-py3 and set LIBS_FROM_GIT to include
> {{zuul.project.name}} in the devstack_localrc vars section. If I
> understand correctly, that would automatically set LIBS_FROM_GIT to
> refer to the project that the job is attached to, which would make it
> easier to use from a project-template (I would also create a
> lib-forward-testing-py3 project template to supplement
> lib-forward-testing).
> 
> Does that sound right?
> 
> Doug

This appears to be working.

https://review.openstack.org/575164 adds a job to oslo.config and the
log shows LIBS_FROM_GIT set to oslo.config's repository:

http://logs.openstack.org/64/575164/1/check/tempest-full-py3-src/7a193fa/job-output.txt.gz#_2018-06-13_19_01_22_742338

How does the QA team feel about hosting the job definition in the
tempest repository with the tempest-full-py3 job? If you think that will
work, I can propose the patch tomorrow.

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-dev] [nova] review runways check-in and feedback

[melanie witt]

Howdy everyone,

We've been experimenting with a new process this cycle, Review Runways 
[1] and we're about at the middle of the cycle now as we had the r-2 
milestone last week June 7.


I wanted to start a thread and gather thoughts and feedback from the 
nova community about how they think runways have been working or not 
working and lend any suggestions to change or improve as we continue on 
in the rocky cycle.


We decided to try the runways process to increase the chances of core 
reviewers converging on the same changes and thus increasing reviews and 
merges on approved blueprint work. As of today, we have 69 blueprints 
approved and 28 blueprints completed, we just passed r-2 June 7 and r-3 
is July 26 and rc1 is August 9 [2].


Do people feel like they've been receiving more review on their 
blueprints? Does it seem like we're completing more blueprints earlier? 
Is there feedback or suggestions for change that you can share?


Thanks all,
-melanie

[1] https://etherpad.openstack.org/p/nova-runways-rocky
[2] https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule

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

[Numan Siddique]

On Thu, Jun 14, 2018 at 12:50 AM, Remo Mattei  wrote:

> Hello guys, just want to double check and make sure that this option can
> be ignored if using vxlan.
>
> NeutronNetworkVLANRanges (used in the network isolation template)
>
>
Hi Remo, this parameter maps to the neutron config 'network_vlan_range'
defined here -
https://github.com/openstack/neutron/blob/master/neutron/conf/plugins/ml2/drivers/driver_type.py#L71

You probably need it if your provider network is VLAN.

Thanks
Numan



> Thanks,
> Remo
>
> __
> 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] PTG Denver 2018 Registration & Hotel Info

[Jeremy Stanley]

On 2018-06-13 14:11:22 -0500 (-0500), Matthew Thode wrote:
[...]
> What if we want that train experience. I feel like there will be
> something missing without it.

Sounds like it may require us to bring our own train whistles.
-- 
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

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

[Rajini.Karthik]

Dell - Internal Use - Confidential

+1

From: Kanevsky, Arkady
Sent: Wednesday, June 13, 2018 12:52 PM
To: ful...@redhat.com; openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on 
storage bits

+1

From: John Fulton [mailto:johfu...@redhat.com]
Sent: Wednesday, June 13, 2018 11:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on 
storage bits

On Wed, Jun 13, 2018, 12:04 PM Marios Andreou 
mailto:mar...@redhat.com>> wrote:

On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente 
mailto:gfide...@redhat.com>> wrote:
On 06/13/2018 05:50 PM, Emilien Macchi wrote:
> Alan Bishop has been highly involved in the Storage backends integration
> in TripleO and Puppet modules, always here to update with new features,
> fix (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
>
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
>
> Please vote -1/+1,

+1 :D

+1


+1




--
Giulio Fidente
GPG KEY: 08D733BA

__
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] TripleO NeutronNetworkVLANRanges

[Remo Mattei]

Hello guys, just want to double check and make sure that this option can be 
ignored if using vxlan. 

NeutronNetworkVLANRanges (used in the network isolation template)

Thanks, 
Remo 
__
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] PTG Denver 2018 Registration & Hotel Info

[Matthew Thode]

On 18-06-13 13:29:54, Kendall Waters wrote:
> The fourth Project Teams Gathering will be held September 10-14th back at the 
> Renaissance Stapleton Hotel in Denver, Colorado (3801 Quebec Street, Denver, 
> Colorado 80207). 
> 
> REGISTRATION AND HOTEL
> Registration is now available here: https://denver2018ptg.eventbrite.com 
>  
> 
> The price is currently USD $399 until August 23 at 6:59 UTC. After that date, 
> the price will be USD $599 so buy your pass before the price increases! 
>  
> We've reserved a very limited block of discounted hotel rooms at $149/night 
> USD (does not include breakfast) with the Renaissance Denver Stapleton Hotel 
> 
>  where the event will be held. Please move quickly to reserve a room by 
> August 20th or until they sell out!
> 
> TRAIN NEAR HOTEL
> The hotel has informed us that the RTD is anticipating the area near the 
> Renaissance Denver Stapleton Hotel being deemed a quiet zone by end of July, 
> with a more realistic completion date of August 15th. This means there should 
> not be any train horns during the week of the PTG! 
>  
> HELPFUL LINKS:
> Registration: https://denver2018ptg.eventbrite.com 
>   
> Visa Invitation Letter (deadline August 24): 
> https://openstackfoundation.formstack.com/forms/visa_form_denver_2018_ptg 
> 
> Travel Support Program (first round deadline July 1): 
> https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 
> 
> Sponsorship: https://www.openstack.org/ptg#tab_sponsor 
> 
> Book a Hotel Room (deadline August 20): 
> https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes
>  
> 
> Feel free to reach out to me directly with any questions, looking forward to 
> seeing everyone in Denver!
> 

What if we want that train experience.  I feel like there will be
something missing without it.

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] PTG Denver 2018 Registration & Hotel Info

[Kendall Waters]

The fourth Project Teams Gathering will be held September 10-14th back at the 
Renaissance Stapleton Hotel in Denver, Colorado (3801 Quebec Street, Denver, 
Colorado 80207). 

REGISTRATION AND HOTEL
Registration is now available here: https://denver2018ptg.eventbrite.com 
 

The price is currently USD $399 until August 23 at 6:59 UTC. After that date, 
the price will be USD $599 so buy your pass before the price increases! 
 
We've reserved a very limited block of discounted hotel rooms at $149/night USD 
(does not include breakfast) with the Renaissance Denver Stapleton Hotel 

 where the event will be held. Please move quickly to reserve a room by August 
20th or until they sell out!

TRAIN NEAR HOTEL
The hotel has informed us that the RTD is anticipating the area near the 
Renaissance Denver Stapleton Hotel being deemed a quiet zone by end of July, 
with a more realistic completion date of August 15th. This means there should 
not be any train horns during the week of the PTG! 
 
HELPFUL LINKS:
Registration: https://denver2018ptg.eventbrite.com 
  
Visa Invitation Letter (deadline August 24): 
https://openstackfoundation.formstack.com/forms/visa_form_denver_2018_ptg 

Travel Support Program (first round deadline July 1): 
https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 

Sponsorship: https://www.openstack.org/ptg#tab_sponsor 

Book a Hotel Room (deadline August 20): 
https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes
 

Feel free to reach out to me directly with any questions, looking forward to 
seeing everyone in Denver!

Cheers,
Kendall

__
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] Proposing Alan Bishop tripleo core on storage bits

[Arkady.Kanevsky]

+1

From: John Fulton [mailto:johfu...@redhat.com]
Sent: Wednesday, June 13, 2018 11:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on 
storage bits

On Wed, Jun 13, 2018, 12:04 PM Marios Andreou 
mailto:mar...@redhat.com>> wrote:

On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente 
mailto:gfide...@redhat.com>> wrote:
On 06/13/2018 05:50 PM, Emilien Macchi wrote:
> Alan Bishop has been highly involved in the Storage backends integration
> in TripleO and Puppet modules, always here to update with new features,
> fix (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
>
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
>
> Please vote -1/+1,

+1 :D

+1


+1




--
Giulio Fidente
GPG KEY: 08D733BA

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

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

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

[Alex Schultz]

+1

On Wed, Jun 13, 2018 at 9:50 AM, Emilien Macchi  wrote:
> Alan Bishop has been highly involved in the Storage backends integration in
> TripleO and Puppet modules, always here to update with new features, fix
> (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
>
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
>
> Please vote -1/+1,
> Thanks!
> --
> 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

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

[John Fulton]

On Wed, Jun 13, 2018, 12:04 PM Marios Andreou  wrote:

>
> On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente 
> wrote:
>
>> On 06/13/2018 05:50 PM, Emilien Macchi wrote:
>> > Alan Bishop has been highly involved in the Storage backends integration
>> > in TripleO and Puppet modules, always here to update with new features,
>> > fix (nasty and untestable third-party backends) bugs and manage all the
>> > backports for stable releases:
>> >
>> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
>> >
>> > He's also well knowledgeable of how TripleO works and how containers are
>> > integrated, I would like to propose him as core on TripleO projects for
>> > patches related to storage things (Cinder, Glance, Swift, Manila, and
>> > backends).
>> >
>> > Please vote -1/+1,
>>
>> +1 :D
>>
>
> +1
>
>

+1



>>
>> --
>> Giulio Fidente
>> GPG KEY: 08D733BA
>>
>> __
>> 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] [qa][python3] advice needed with updating lib-forward-testing jobs

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-13 10:31:00 -0400:
> Excerpts from Ghanshyam's message of 2018-06-13 16:52:33 +0900:
> >   On Wed, 13 Jun 2018 05:09:03 +0900 Doug Hellmann 
> >  wrote  
> >  > I would like to create a version of the jobs that run as part of
> >  > lib-forward-testing (legacy-tempest-dsvm-neutron-src) that works under
> >  > python 3. I'm not sure the best way to proceed, since that's a legacy
> >  > job.
> >  > 
> >  > I'm not sure I'm familiar enough with the job to port it to be
> >  > zuulv3 native and allow us to drop the "legacy". Should I just
> >  > duplicate that job and modify it and keep the new one as "legacy"
> >  > too?
> >  > 
> >  > Is there a different job I should base the work on? I don't see anything
> >  > obvious in the tempest repo's .zuul.yaml file.
> > 
> > I had a quick glance of this job (legacy-tempest-dsvm-neutron-src) and it 
> > is similar to tempest-full-py3 job except it override the LIBS_FROM_GIT 
> > with corresponding lib. tempest-full-py3 job is py3 based with tempest-full 
> > tests running and disable the swift services 
> > 
> > You can create a new job (something tempest-full-py3-src) derived from 
> > 'tempest-full-py3' if all set var is ok for you like disable swift OR 
> > derived  'devstack-tempest' and then build other var similar to 
> > 'tempest-full-py3'.  Extra things you need to do is to add libs you want to 
> > override in 'required_project' list (FYI- 
> > Now LIBS_FROM_GIT is automatically set based on required projects [2]) .
> > 
> > Later, old job (legacy-tempest-dsvm-neutron-src) can be migrated separately 
> > if needed to run or removed. 
> > 
> > But I am not sure which repo  should own this new job.
> 
> Could it be as simple as adding tempest-full-py3 with the
> required-projects list updated to include the current repository? So
> there isn't a special separate job, and we would just reuse
> tempest-full-py3 for this?
> 
> It would be less "automatic" than the current project-template and job,
> but still relatively simple to set up. Am I missing something? This
> feels too easy...

I think I could define a job with a name like tempest-full-py3-src based
on tempest-full-py3 and set LIBS_FROM_GIT to include
{{zuul.project.name}} in the devstack_localrc vars section. If I
understand correctly, that would automatically set LIBS_FROM_GIT to
refer to the project that the job is attached to, which would make it
easier to use from a project-template (I would also create a
lib-forward-testing-py3 project template to supplement
lib-forward-testing).

Does that sound 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] [tripleo] Proposing Alan Bishop tripleo core on storage bits

[Marios Andreou]

On Wed, Jun 13, 2018 at 6:57 PM, Giulio Fidente  wrote:

> On 06/13/2018 05:50 PM, Emilien Macchi wrote:
> > Alan Bishop has been highly involved in the Storage backends integration
> > in TripleO and Puppet modules, always here to update with new features,
> > fix (nasty and untestable third-party backends) bugs and manage all the
> > backports for stable releases:
> > https://review.openstack.org/#/q/owner:%22Alan+Bishop+%
> 253Cabishop%2540redhat.com%253E%22
> >
> > He's also well knowledgeable of how TripleO works and how containers are
> > integrated, I would like to propose him as core on TripleO projects for
> > patches related to storage things (Cinder, Glance, Swift, Manila, and
> > backends).
> >
> > Please vote -1/+1,
>
> +1 :D
>

+1


>
>
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
> __
> 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] Proposing Alan Bishop tripleo core on storage bits

[Giulio Fidente]

On 06/13/2018 05:50 PM, Emilien Macchi wrote:
> Alan Bishop has been highly involved in the Storage backends integration
> in TripleO and Puppet modules, always here to update with new features,
> fix (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
> 
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
> 
> Please vote -1/+1,

+1 :D


-- 
Giulio Fidente
GPG KEY: 08D733BA

__
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] Proposing Alan Bishop tripleo core on storage bits

[Emilien Macchi]

Alan Bishop has been highly involved in the Storage backends integration in
TripleO and Puppet modules, always here to update with new features, fix
(nasty and untestable third-party backends) bugs and manage all the
backports for stable releases:
https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22

He's also well knowledgeable of how TripleO works and how containers are
integrated, I would like to propose him as core on TripleO projects for
patches related to storage things (Cinder, Glance, Swift, Manila, and
backends).

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

Re: [openstack-dev] [horizon][plugins] Introduce horizonlib (again)

[Doug Hellmann]

Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300:
> Hi team,
> 
> Last week on the Horizon meeting we discussed [1] possible options for
> Horizon release model to address current issues for plugins maintainers.
> Some background could be found here [2].
> 
> The main issue is that we should have some stable API for plugins and be
> able to release it as needed. We're trying to cover several use cases with
> this effort. E.g:
> - do not break plugins with Horizon changes (cross-project CI would help
> with some issues here too)
> - provide an easy way to develop plugins which require specific Horizon
> version and features
> 
> For now, most of the plugins use 'horizon' package to implement
> dashboard extensions. Some plugins use parts of 'openstack_dashboard'
> package. In such case, it becomes complicated to develop plugins based on
> current master and have CI up and running.
> 
> The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with
> a stable API for plugin development. We're going to collect everything
> needed for this library, so plugins developers could consume only it and do
> not relate on any internal Horizon things.
> 
> We'd got horizonlib in the past. Unfortunately, we missed information about
> what was good or bad but we'll do our best to succeed in this.
> 
> 
> If you have any comments or questions, please do not hesitate to drop few
> words into this conversation or ping me in IRC. We're going to collect as
> much feedback as we can before we'll discuss it in details during the next
> PTG.
> 
> 
> [1]
> http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/

Another solution that may end up being less work is to release Horizon
using the cycle-with-intermediary model and publish the releases to
PyPI. Those two changes would let you release changes at any point in
the cycle, to support your plugin authors, and would not require
reorganizing the code in Horizon to build a new release artifact.

The release team would be happy to offer advice about how to make the
changes, if you want to talk about it.

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] [requirements][daisycloud][freezer][fuel][tatu][trove] pycrypto is dead and insecure, you should migrate

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-13 10:23:45 -0500:
> On 18-06-13 20:53:06, Rong Zhu wrote:
> > Hi, Matthew
> > 
> > Solum removed pycryto dependency in [0]
> > 
> > [0]: https://review.openstack.org/#/c/574244/
> > 
> > -- 
> > Thanks,
> > Rong Zhu
> 
> Yep, just in time for the next reminder email too :D
> 
> > ++-+--+---+
> > | Repository | Filename 
> >| Line | Text
> >   |
> > ++-+--+---+
> > | daisycloud-core| code/daisy/requirements.txt  
> >|   17 | pycrypto>=2.6 # Public Domain   
> >   |
> > | freezer| requirements.txt 
> >|   21 | pycrypto>=2.6 # Public Domain   
> >   |
> > | fuel-dev-tools | 
> > contrib/fuel-setup/requirements.txt |5 
> > | pycrypto==2.6.1   |
> > | fuel-web   | nailgun/requirements.txt 
> >|   24 | pycrypto>=2.6.1 
> >   |
> > | tatu   | requirements.txt 
> >|7 | pycrypto>=2.6.1 
> >   |
> > | tatu   | test-requirements.txt
> >|7 | pycrypto>=2.6.1 
> >   |
> > | trove  | 
> > integration/scripts/files/requirements/fedora-requirements.txt  |   30 
> > | pycrypto>=2.6  # Public Domain|
> > | trove  | 
> > integration/scripts/files/requirements/ubuntu-requirements.txt  |   29 
> > | pycrypto>=2.6  # Public Domain|
> > | trove  | requirements.txt 
> >|   47 | pycrypto>=2.6 # Public Domain   
> >   |
> > ++-+--+---+
> 
> Reverse order this time :D
> 
> trove has https://review.openstack.org/#/c/573070 which is making good
> progress
> 
> The rest (tatu, fuel, freezer, daisycloud-core) I don't see any reviews,
> starting to wonder if they watch the list.
> 

Given the requirements team's limited resources, I would focus on
freezer and trove. The other projects aren't official, and we can
address any issues they have if they apply to become official.

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] [requirements][daisycloud][freezer][fuel][tatu][trove] pycrypto is dead and insecure, you should migrate

[Matthew Thode]

On 18-06-13 20:53:06, Rong Zhu wrote:
> Hi, Matthew
> 
> Solum removed pycryto dependency in [0]
> 
> [0]: https://review.openstack.org/#/c/574244/
> 
> -- 
> Thanks,
> Rong Zhu

Yep, just in time for the next reminder email too :D

> ++-+--+---+
> | Repository | Filename   
>  | Line | Text
>   |
> ++-+--+---+
> | daisycloud-core| code/daisy/requirements.txt
>  |   17 | pycrypto>=2.6 # Public Domain   
>   |
> | freezer| requirements.txt   
>  |   21 | pycrypto>=2.6 # Public Domain   
>   |
> | fuel-dev-tools | 
> contrib/fuel-setup/requirements.txt |5 | 
> pycrypto==2.6.1   |
> | fuel-web   | nailgun/requirements.txt   
>  |   24 | pycrypto>=2.6.1 
>   |
> | tatu   | requirements.txt   
>  |7 | pycrypto>=2.6.1 
>   |
> | tatu   | test-requirements.txt  
>  |7 | pycrypto>=2.6.1 
>   |
> | trove  | 
> integration/scripts/files/requirements/fedora-requirements.txt  |   30 | 
> pycrypto>=2.6  # Public Domain|
> | trove  | 
> integration/scripts/files/requirements/ubuntu-requirements.txt  |   29 | 
> pycrypto>=2.6  # Public Domain|
> | trove  | requirements.txt   
>  |   47 | pycrypto>=2.6 # Public Domain   
>   |
> ++-+--+---+

Reverse order this time :D

trove has https://review.openstack.org/#/c/573070 which is making good
progress

The rest (tatu, fuel, freezer, daisycloud-core) I don't see any reviews,
starting to wonder if they watch the list.

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] Reminder to add "nova-status upgrade check" to deployment tooling

[Matt Riedemann]

I was going through some recently reported nova bugs and came across [1] 
which I opened at the Summit during one of the FFU sessions where I 
realized the nova upgrade docs don't mention the nova-status upgrade 
check CLI [2] (added in Ocata).


As a result, I was wondering how many deployment tools out there support 
upgrades and from those, which are actually integrating that upgrade 
status check command.


I'm not really familiar with most of them, but I've dabbled in OSA 
enough to know where the code lived for nova upgrades, so I posted a 
patch [3].


I'm hoping this can serve as a template for other deployment projects to 
integrate similar checks into their upgrade (and install verification) 
flows.


[1] https://bugs.launchpad.net/nova/+bug/1772973
[2] https://docs.openstack.org/nova/latest/cli/nova-status.html
[3] https://review.openstack.org/#/c/575125/

--

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

[openstack-dev] [horizon][plugins] Introduce horizonlib (again)

[Ivan Kolodyazhny]

Hi team,

Last week on the Horizon meeting we discussed [1] possible options for
Horizon release model to address current issues for plugins maintainers.
Some background could be found here [2].

The main issue is that we should have some stable API for plugins and be
able to release it as needed. We're trying to cover several use cases with
this effort. E.g:
- do not break plugins with Horizon changes (cross-project CI would help
with some issues here too)
- provide an easy way to develop plugins which require specific Horizon
version and features

For now, most of the plugins use 'horizon' package to implement
dashboard extensions. Some plugins use parts of 'openstack_dashboard'
package. In such case, it becomes complicated to develop plugins based on
current master and have CI up and running.

The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with
a stable API for plugin development. We're going to collect everything
needed for this library, so plugins developers could consume only it and do
not relate on any internal Horizon things.

We'd got horizonlib in the past. Unfortunately, we missed information about
what was good or bad but we'll do our best to succeed in this.


If you have any comments or questions, please do not hesitate to drop few
words into this conversation or ping me in IRC. We're going to collect as
much feedback as we can before we'll discuss it in details during the next
PTG.


[1]
http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html

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

Re: [openstack-dev] [keystone] Signing off

[David Stanek]

On 30-May-2018 08:45, Henry Nash wrote:
> Hi
>  
> It is with a somewhat heavy heart that I have decided that it is time to hang
> up my keystone core status. Having been involved since the closing stages of
> Folsom, I've had a good run! When I look at how far keystone has come since 
> the
> v2 days, it is remarkable - and we should all feel a sense of pride in that.
>  
> Thanks to all the hard work, commitment, humour and support from all the
> keystone folks over the years - I am sure we will continue to interact and 
> meet
> among the many other open source projects that many of us are becoming 
> involved
> with. Ad astra!
>  

Hey Henry!

It's good to hear from you! You were always fun to work with and I got a
lot out of our chats about crazy, enterprisey things. I guess the world
with have to wait for another episode of "Stanek & Nash".

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek

__
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] [qa][python3] advice needed with updating lib-forward-testing jobs

[Doug Hellmann]

Excerpts from Ghanshyam's message of 2018-06-13 16:52:33 +0900:
>   On Wed, 13 Jun 2018 05:09:03 +0900 Doug Hellmann 
>  wrote  
>  > I would like to create a version of the jobs that run as part of
>  > lib-forward-testing (legacy-tempest-dsvm-neutron-src) that works under
>  > python 3. I'm not sure the best way to proceed, since that's a legacy
>  > job.
>  > 
>  > I'm not sure I'm familiar enough with the job to port it to be
>  > zuulv3 native and allow us to drop the "legacy". Should I just
>  > duplicate that job and modify it and keep the new one as "legacy"
>  > too?
>  > 
>  > Is there a different job I should base the work on? I don't see anything
>  > obvious in the tempest repo's .zuul.yaml file.
> 
> I had a quick glance of this job (legacy-tempest-dsvm-neutron-src) and it is 
> similar to tempest-full-py3 job except it override the LIBS_FROM_GIT with 
> corresponding lib. tempest-full-py3 job is py3 based with tempest-full tests 
> running and disable the swift services 
> 
> You can create a new job (something tempest-full-py3-src) derived from 
> 'tempest-full-py3' if all set var is ok for you like disable swift OR derived 
>  'devstack-tempest' and then build other var similar to 'tempest-full-py3'.  
> Extra things you need to do is to add libs you want to override in 
> 'required_project' list (FYI- 
> Now LIBS_FROM_GIT is automatically set based on required projects [2]) .
> 
> Later, old job (legacy-tempest-dsvm-neutron-src) can be migrated separately 
> if needed to run or removed. 
> 
> But I am not sure which repo  should own this new job.

Could it be as simple as adding tempest-full-py3 with the
required-projects list updated to include the current repository? So
there isn't a special separate job, and we would just reuse
tempest-full-py3 for this?

It would be less "automatic" than the current project-template and job,
but still relatively simple to set up. Am I missing something? This
feels too easy...

Doug

> 
> [1] 
> https://github.com/openstack/tempest/blob/67e99b5b45d18f8fd28dbe3b09bd75008267176e/.zuul.yaml#L61
> [2] https://review.openstack.org/#/c/549252/
> 
> -gmann
> 
>  > 
>  > Thanks,
>  > 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] [tc] [summary] Organizational diversity tag

[Doug Hellmann]

Excerpts from Jean-Philippe Evrard's message of 2018-06-13 11:04:51 +0200:
> > - Drop tags, write a regular report instead that can account for the
> > subtlety of each situation (ttx). One issue here is that it's obviously a
> > lot more work than the current situation.
> 
> That's what I'd prefer personally.

Who would do that work?

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-dev] [cyborg]Team Weekly Meeting 2018.06.13

[Zhipeng Huang]

Hi Team,

Kind reminder for the team meeting today about 30 mins later at
#openstack-cyborg .

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] config-download/ansible next steps

[Sergii Golovatiuk]

Hi,

On Wed, Jun 13, 2018 at 3:17 PM, James Slagle  wrote:
> On Wed, Jun 13, 2018 at 6:49 AM, Dmitry Tantsur  wrote:
>> Slightly hijacking the thread to provide a status update on one of the items
>> :)
>
> Thanks for jumping in.
>
>
>> The immediate plan right now is to wait for metalsmith 0.4.0 to hit the
>> repositories, then start experimenting. I need to find a way to
>> 1. make creating nova instances no-op
>> 2. collect the required information from the created stack (I need networks,
>> ports, hostnames, initial SSH keys, capabilities, images)
>> 3. update the config-download code to optionally include the role [2]
>> I'm not entirely sure where to start, so any hints are welcome.
>
> Here are a couple of possibilities.
>
> We could reuse the OS::TripleO::{{role.name}}Server mappings that we
> already have in place for pre-provisioned nodes (deployed-server).
> This could be mapped to a template that exposes some Ansible tasks as
> outputs that drives metalsmith to do the deployment. When
> config-download runs, it would execute these ansible tasks to
> provision the nodes with Ironic. This has the advantage of maintaining
> compatibility with our existing Heat parameter interfaces. It removes
> Nova from the deployment so that from the undercloud perspective you'd
> roughly have:
>
> Mistral -> Heat -> config-download -> Ironic (driven via ansible/metalsmith)
>
> A further (or completely different) iteration might look like:
>
> Step 1: Mistral -> Ironic (driven via ansible/metalsmith)
> Step 2: Heat -> config-download

I really like this approach. It decouples provisioning level from
deployment. As a result we may use better level of parallelism. For
instance, when we have 3 provisioned servers that match controller
roles we may start controller deployment without waiting other nodes
provisioning. For Compute role the strategy may be different such as
deploy Compute server when at least one node provisioned.

>
> Step 2 would use the pre-provisioned node (deployed-server)  feature
> already existing in TripleO and treat the just provisioned by Ironic
> nodes, as pre-provisioned from the Heat stack perspective. Step 1 and
> Step 2 would also probably be driven by a higher level Mistral
> workflow. This has the advantage of minimal impact to
> tripleo-heat-templates, and also removes Heat from the baremetal
> provisioning step. However, we'd likely need some python compatibility
> libraries that could translate Heat parameter values such as
> HostnameMap to ansible vars for some basic backwards compatibility.
>
>>
>> [1] https://github.com/openstack/metalsmith
>> [2] https://metalsmith.readthedocs.io/en/latest/user/ansible.html
>>
>>>
>>> Obviously we have things to consider here such as backwards compatibility
>>> and
>>> upgrades, but overall, I think this would be a great simplification to our
>>> overall deployment workflow.
>>>
>>
>> Yeah, this is tricky. Can we make Heat "forget" about Nova instances? Maybe
>> by re-defining them to OS::Heat::None?
>
> Not exactly, as Heat would delete the previous versions of the
> resources. We'd need some special migrations, or could support the
> existing method forever for upgrades, and only deprecate it for new
> deployments.
>
> I'd like to help with this work. I'll start by taking a look at what
> you've got so far. Feel free to reach out if you'd like some
> additional dev assistance or testing.
>
> --
> -- James Slagle
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best Regards,
Sergii Golovatiuk

__
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] config-download/ansible next steps

[James Slagle]

On Wed, Jun 13, 2018 at 6:49 AM, Dmitry Tantsur  wrote:
> Slightly hijacking the thread to provide a status update on one of the items
> :)

Thanks for jumping in.


> The immediate plan right now is to wait for metalsmith 0.4.0 to hit the
> repositories, then start experimenting. I need to find a way to
> 1. make creating nova instances no-op
> 2. collect the required information from the created stack (I need networks,
> ports, hostnames, initial SSH keys, capabilities, images)
> 3. update the config-download code to optionally include the role [2]
> I'm not entirely sure where to start, so any hints are welcome.

Here are a couple of possibilities.

We could reuse the OS::TripleO::{{role.name}}Server mappings that we
already have in place for pre-provisioned nodes (deployed-server).
This could be mapped to a template that exposes some Ansible tasks as
outputs that drives metalsmith to do the deployment. When
config-download runs, it would execute these ansible tasks to
provision the nodes with Ironic. This has the advantage of maintaining
compatibility with our existing Heat parameter interfaces. It removes
Nova from the deployment so that from the undercloud perspective you'd
roughly have:

Mistral -> Heat -> config-download -> Ironic (driven via ansible/metalsmith)

A further (or completely different) iteration might look like:

Step 1: Mistral -> Ironic (driven via ansible/metalsmith)
Step 2: Heat -> config-download

Step 2 would use the pre-provisioned node (deployed-server)  feature
already existing in TripleO and treat the just provisioned by Ironic
nodes, as pre-provisioned from the Heat stack perspective. Step 1 and
Step 2 would also probably be driven by a higher level Mistral
workflow. This has the advantage of minimal impact to
tripleo-heat-templates, and also removes Heat from the baremetal
provisioning step. However, we'd likely need some python compatibility
libraries that could translate Heat parameter values such as
HostnameMap to ansible vars for some basic backwards compatibility.

>
> [1] https://github.com/openstack/metalsmith
> [2] https://metalsmith.readthedocs.io/en/latest/user/ansible.html
>
>>
>> Obviously we have things to consider here such as backwards compatibility
>> and
>> upgrades, but overall, I think this would be a great simplification to our
>> overall deployment workflow.
>>
>
> Yeah, this is tricky. Can we make Heat "forget" about Nova instances? Maybe
> by re-defining them to OS::Heat::None?

Not exactly, as Heat would delete the previous versions of the
resources. We'd need some special migrations, or could support the
existing method forever for upgrades, and only deprecate it for new
deployments.

I'd like to help with this work. I'll start by taking a look at what
you've got so far. Feel free to reach out if you'd like some
additional dev assistance or testing.

-- 
-- James Slagle
--

__
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] [requirements][daisycloud][freezer][fuel][solum][tatu][trove] pycrypto is dead and insecure, you should migrate part 2

[Rong Zhu]

Hi, Matthew

Solum removed pycryto dependency in [0]

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

-- 
Thanks,
Rong Zhu



On Tue, Jun 5, 2018 at 3:07 AM Matthew Thode 
wrote:

> On 18-05-13 12:22:06, Matthew Thode wrote:
> > This is a reminder to the projects called out that they are using old,
> > unmaintained and probably insecure libraries (it's been dead since
> > 2014).  Please migrate off to use the cryptography library.  We'd like
> > to drop pycrypto from requirements for rocky.
> >
> > See also, the bug, which has most of you cc'd already.
> >
> > https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> >
>
>
> ++-+--+---+
> | Repository | Filename
> | Line | Text
> |
>
> ++-+--+---+
> | daisycloud-core| code/daisy/requirements.txt
>  |   17 | pycrypto>=2.6 # Public
> Domain |
> | freezer| requirements.txt
> |   21 | pycrypto>=2.6 # Public Domain
>|
> | fuel-dev-tools |
> contrib/fuel-setup/requirements.txt |5
> | pycrypto==2.6.1   |
> | fuel-web   | nailgun/requirements.txt
> |   24 | pycrypto>=2.6.1
>|
> | solum  | requirements.txt
> |   24 | pycrypto # Public Domain
> |
> | tatu   | requirements.txt
> |7 | pycrypto>=2.6.1
>|
> | tatu   | test-requirements.txt
>  |7 | pycrypto>=2.6.1
>  |
> | trove  |
> integration/scripts/files/requirements/fedora-requirements.txt  |   30
> | pycrypto>=2.6  # Public Domain|
> | trove  |
> integration/scripts/files/requirements/ubuntu-requirements.txt  |   29
> | pycrypto>=2.6  # Public Domain|
> | trove  | requirements.txt
> |   47 | pycrypto>=2.6 # Public Domain
>|
>
> ++-+--+---+
>
> In order by name, notes follow.
>
> daisycloud-core - looks like AES / random functions are used
> freezer - looks like AES / random functions are used
> solum   - looks like AES / RSA functions are used
> trove   - has a review!!! https://review.openstack.org/#/c/560292/
>
> The following projects are not tracked so we won't wait on them.
> fuel-dev-tools, fuel-web, tatu
>
> so it looks like progress is being made, so we have that going for us,
> which is nice.  What can I do to help move this forward?
>
> --
> Matthew Thode (prometheanfire)
> __
> 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
>


-- 
Thanks,
Rong Zhu
__
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] [release] How to handle "stable" deliverables releases

[Thomas Goirand]

On 06/11/2018 11:53 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> As some of the OpenStack deliverables get more mature, we need to adjust
> our release policies to best handle the case of deliverables that do not
> need to be updated that much. This discussion started with how to handle
> those "stable" libraries, but is actually also relevant for "stable"
> services.
> 
> Our current models include cycle-tied models (with-intermediary,
> with-milestones, trailing) and a purely cycle-independent model. Main
> OpenStack deliverables (the service components that you can deploy to
> build an OpenStack cloud) are all "released" on a cycle. Libraries are
> typically maintained per-cycle as well. What happens if no change is
> pushed to a service or library during a full cycle ? What should we do
> then ?
> 
> Options include:
> 
> 1/ Force artificial releases, even if there are no changes
> 2/ Do not force releases, but still create branches from latest releases
> 2bis/ Like 2, but only create the branch when needed
> 3/ Do not force releases, and reuse stable branches from cycle to cycle
> 4/ Stop worrying about stable branches at all for those "stable" things

FYI, for downstream distribution maintainers, any evolution from 1/ is
fine: it's a bit silly for us to just rebuild a new package when there's
no need for it. It's a waste of time for package maintainer, and users
who have to download the new version, etc. We're not really concerned by
branches, all we care is if there's a new tag to be packaged.

Cheers,

Thomas Goirand (zigo)

__
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] [docs] Documentation meeting canceled

[Petr Kovar]

Hi all,

Apologies but have to cancel today's docs meeting due to a meeting
conflict. 

Have questions for the docs team? We hang out at #openstack-doc.

Thanks,
pk

__
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] config-download/ansible next steps

[Dmitry Tantsur]

Slightly hijacking the thread to provide a status update on one of the items :)

On 06/12/2018 07:04 PM, James Slagle wrote:

I wanted to provide an update on some next steps around config-download/Ansible
and TripleO. Now that we've completed transitioning to config-download by
default in Rocky, some might be wondering where we're going next.





4. Ansible driven baremetal deployment

Dmitry Tantsur has indicated he's going to be looking at driving TripleO
baremetal provisioning with Ironic and ansible directly. This would remove
Heat+Nova from the baremetal provisioning workflows we currently use.


I'm actually already looking, my efforts just have not become visible yet.

I started with reviving my old metalsmith project [1] to host the code we need 
to make this happen. This now has a CLI tool and a very dump (for now) ansible 
role [2] to drive it.


Why a new tool? First, I want it to be reusable outside of TripleO (and outside 
of ansible modules), thus I don't want to put the code directly into, say, 
tripleo-common. Second, the current OpenStack Ansible modules are not quite 
sufficient for the task:


1. Both the os_ironic_node module and the underlying openstacksdk library lack 
support for the critically important VIF attachment API. I'm working on 
addressing that, but it will take substantial time (e.g. we need to stabilize 
the microversion support in openstacksdk).


2. Missing support for building configdrive. Again, can probably be added to 
openstacksdk, and I'll get to it one day.


3. No bulk operations. There is no way, to my best knowledge (please tell me I'm 
wrong), to provision several nodes in parallel via the current ansible modules. 
It is probably solvable via a new ansible module, but also see the next points.


4. No scheduling. That is, there is no way out-of-box to pick a suitable node 
for deployment. It can be done in pure ansible in the simplest case, but our 
case is not the simplest. Particularly, I don't want to end up parsing 
capabilities in ansible :) Also one of the goals of this work is to provide 
better messages than "No valid hosts found".


5. On top of #3 and #4, it is not possible to operate at the deployment level, 
not on the node level. From the current Heat stack we're going to receive a list 
of overcloud instances with their roles and other parameters. Some code has to 
take this input and make a decision on whether to deploy/undeploy something. 
It's currently done by Heat+Nova together, but they're not doing a great job in 
some corner cases. Particularly, replacing a node may be painful.


So, while I do plan to solve #1 and #2 eventually, #3 - #5 require some place to 
put the logic. Putting it to TripleO or to ansible itself will preclude reusing 
it outside of TripleO and ansible accordingly. So, metalsmith is this place for 
now. I think in the far future I will try proposing a module to ansible itself 
that will handle #3 - #5 and will be backed by metalsmith. It will probably have 
a similar interface to the current PoC role [2].


The immediate plan right now is to wait for metalsmith 0.4.0 to hit the 
repositories, then start experimenting. I need to find a way to

1. make creating nova instances no-op
2. collect the required information from the created stack (I need networks, 
ports, hostnames, initial SSH keys, capabilities, images)

3. update the config-download code to optionally include the role [2]
I'm not entirely sure where to start, so any hints are welcome.

[1] https://github.com/openstack/metalsmith
[2] https://metalsmith.readthedocs.io/en/latest/user/ansible.html



Obviously we have things to consider here such as backwards compatibility and
upgrades, but overall, I think this would be a great simplification to our
overall deployment workflow.



Yeah, this is tricky. Can we make Heat "forget" about Nova instances? Maybe by 
re-defining them to OS::Heat::None?


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] [openstack-ansible] Restarting our very own "SIG" teams

[Jean-Philippe Evrard]

Hello,

TL:DR; If you have spare cycles, join one of our interest groups!

In the Queens cycle, I have formalised the "liaisons" work, making
them an integral part of the Thursday's meeting agenda. Sadly, that
initiative didn't work, as almost no liaison worked/reported on those
meetings, and I stopped the initiative.

Upon common agreement that we now need to change how we scale the
team, we will now start our "liaison 2.0" work.

So, I have started an etherpad [1], where you could see all the
"groups" of people that OSA need, and where you could help.

Please don't hesitate to edit this etherpad, adding your new special
interest group, or simply joining an existing one if you have spare
cycles!

Thank you!

Jean-Philippe Evrard (evrardjp)

[1]: https://etherpad.openstack.org/p/osa-liaisons

__
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] [summary] Organizational diversity tag

[Jean-Philippe Evrard]

> - Drop tags, write a regular report instead that can account for the
> subtlety of each situation (ttx). One issue here is that it's obviously a
> lot more work than the current situation.

That's what I'd prefer personally.

We have a website with a nice project navigator now [1].
This is somewhat a reference IMO, and should always be up to date for
the published releases.

The information is generated, but it could now as well be a static
file/source of truth that we update and peer review manually after a
cycle.
It could allow more flexible and case by case data.

This also make the information easy to find: that's naturally where
I'd go (if I was an end-user) to see information about a project, not
the governance repo.
Although now I have learnt, and I am not sure this is worth spending
much effort.

[1]: https://www.openstack.org/software/project-navigator/

__
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] [watcher] Nominating suzhengwei as Watcher core

[Aditi Sharma]

+1


Thanks and Regards,
Aditi
IRC: adisky
-Original Message-
From: Hidekazu Nakamura [mailto:hid-nakam...@vf.jp.nec.com] 
Sent: 13 June 2018 13:48
To: OpenStack Development Mailing List (not for usage questions)
Cc: Masahiko Hayashi
Subject: Re: [openstack-dev] [watcher] Nominating suzhengwei as Watcher core

+1

Sorry for the long delay.

> -Original Message-
> From: Чадин Александр Сергеевич
> [mailto:ascha...@sbcloud.ru]
> Sent: Tuesday, June 5, 2018 5:27 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: [openstack-dev] [watcher] Nominating suzhengwei as Watcher 
> core
> 
> Hi Watchers,
> 
> I’d like to nominate suzhengwei for Watcher Core team.
> 
> suzhengwei makes great contribution to the Watcher project including 
> code reviews and implementations.
> 
> Please vote +1/-1.
> 
> 
> Best Regards,
> 
> Alex
__
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] [release] How to handle "stable" deliverables releases

[Jean-Philippe Evrard]

Option 2 for me. And the option switch to independant is IMO just fine.

__
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] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Bedyk, Witold]

Hello Telemetry Team,

We would like to contribute a Monasca publisher to Ceilometer project [1] and 
add it to the list of currently supported transports [2].
The goal of the plugin is to send Ceilometer samples to Monasca API.

I understand Gordon's concerns about adding maintenance overhead for Ceilometer 
team which he expressed in review but the code is pretty much self-contained 
and does not affect Ceilometer core. It's not our intention to shift the 
maintenance effort and Monasca team should still be responsible for this code.

Adding this plugin will help in terms of interoperability of both projects and 
can be useful for wider parts of the OpenStack community.

Please let me know your thoughts. I hope we can get this code merged.

Cheers
Witek


[1] https://review.openstack.org/562400
[2] 
https://docs.openstack.org/ceilometer/latest/contributor/architecture.html#processing-the-data

__
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] [watcher] Nominating suzhengwei as Watcher core

[Hidekazu Nakamura]

+1

Sorry for the long delay.

> -Original Message-
> From: Чадин Александр Сергеевич
> [mailto:ascha...@sbcloud.ru]
> Sent: Tuesday, June 5, 2018 5:27 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [watcher] Nominating suzhengwei as Watcher core
> 
> Hi Watchers,
> 
> I’d like to nominate suzhengwei for Watcher Core team.
> 
> suzhengwei makes great contribution to the Watcher project including code
> reviews and implementations.
> 
> Please vote +1/-1.
> 
> 
> Best Regards,
> 
> Alex
__
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] [qa][python3] advice needed with updating lib-forward-testing jobs

[Ghanshyam]

  On Wed, 13 Jun 2018 05:09:03 +0900 Doug Hellmann  
wrote  
 > I would like to create a version of the jobs that run as part of
 > lib-forward-testing (legacy-tempest-dsvm-neutron-src) that works under
 > python 3. I'm not sure the best way to proceed, since that's a legacy
 > job.
 > 
 > I'm not sure I'm familiar enough with the job to port it to be
 > zuulv3 native and allow us to drop the "legacy". Should I just
 > duplicate that job and modify it and keep the new one as "legacy"
 > too?
 > 
 > Is there a different job I should base the work on? I don't see anything
 > obvious in the tempest repo's .zuul.yaml file.

I had a quick glance of this job (legacy-tempest-dsvm-neutron-src) and it is 
similar to tempest-full-py3 job except it override the LIBS_FROM_GIT with 
corresponding lib. tempest-full-py3 job is py3 based with tempest-full tests 
running and disable the swift services 

You can create a new job (something tempest-full-py3-src) derived from 
'tempest-full-py3' if all set var is ok for you like disable swift OR derived  
'devstack-tempest' and then build other var similar to 'tempest-full-py3'.  
Extra things you need to do is to add libs you want to override in 
'required_project' list (FYI- 
Now LIBS_FROM_GIT is automatically set based on required projects [2]) .

Later, old job (legacy-tempest-dsvm-neutron-src) can be migrated separately if 
needed to run or removed. 

But I am not sure which repo  should own this new job.

[1] 
https://github.com/openstack/tempest/blob/67e99b5b45d18f8fd28dbe3b09bd75008267176e/.zuul.yaml#L61
[2] https://review.openstack.org/#/c/549252/

-gmann

 > 
 > Thanks,
 > 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-dev] [kolla] Propose move the weekly meeting one hour earlier

[Jeffrey Zhang]

As we have more and more developer located in Asia and Europe timezone
rather
than Americas'.  Current weekly meeting time is not proper.  This was
discussed
at the last meeting and as a result, seems one hour earlier then now is
better
than now.

So I propose to move the weekly meeting from UTC 16:00 to UTC 15:00 on
Wednesday.  Feel free to vote on the patch[0]

This patch will be opened until next weekly meeting, 20 June.

[0] https://review.openstack.org/575011
-- 
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

Re: [openstack-dev] [tap-as-a-service] core reviewer update

[Takashi Yamamoto]

i just made the change as i haven't got any concerns.
welcome, kaz!

On Thu, May 31, 2018 at 2:36 PM, Takashi Yamamoto  wrote:
> hi,
>
> i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
> he is one of active members of the project.
> he is also the original author of tap-as-a-service-dashboard.
> i'll make the change after a week unless i hear any objections/concerns.
>
> [1] https://review.openstack.org/#/admin/groups/957,members
> http://stackalytics.com/report/contribution/tap-as-a-service/120

__
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