Re: [openstack-dev] [nova] About live-resize spec

[Claudiu Belu]

Hello,

I am willing to restart working on it, if it actually has a chance of getting 
approved. Last time, the spec got 2 x +2's and ~12 +1's [1].

I don't know how soon the capabilities thing can become a real thing, but IMO, 
we can go with Matt's suggestion of disabling the feature by default through 
policy.

Restored and reproposed the spec for Queens btw.

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

Best regards,

Claudiu Belu


From: Chen CH Ji [jiche...@cn.ibm.com]
Sent: Thursday, September 21, 2017 8:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] About live-resize spec


ok, thanks, I will pick up and get Claudiu's help as well, the original spec is 
abandoned ,could you please help to restore it?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC

[Inactive hide details for Matt Riedemann ---09/20/2017 09:11:39 PM---On 
9/20/2017 12:16 AM, Chen CH Ji wrote: > spec [1] has be]Matt Riedemann 
---09/20/2017 09:11:39 PM---On 9/20/2017 12:16 AM, Chen CH Ji wrote: > spec [1] 
has been there since 2014 and some patches propo

From: Matt Riedemann 
To: openstack-dev@lists.openstack.org
Date: 09/20/2017 09:11 PM
Subject: Re: [openstack-dev] [nova] About live-resize spec





On 9/20/2017 12:16 AM, Chen CH Ji wrote:
> spec [1] has been there since 2014 and some patches proposed but
> abandoned after that, can someone
> please provide some info/background about why it's postponed or due to
> some limitations that nova hasn't been implemented yet?
>
> some operators suggested that this is a valuable funcationality so
> better to have it in the near feature... thanks
>
>
> [1]:https://urldefense.proofpoint.com/v2/url?u=https-3A__blueprints.launchpad.net_nova_-2Bspec_instance-2Dlive-2Dresize&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE&s=_CAt9-g8ZEY5LXXo10rhhd-GMWz4B1YBQ28dhuFZnj0&e=
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE&s=anotHeOxKU8HE2ff2CnYn4rwT48cG1wkINchYamlckw&e=
>

We talked about this during the newton midcycle and from what I remember
we wanted to make this depend on having the ability for users to know
what they are capable of doing with their server instance in any given
cloud. This has grown into the cross project capabilities API
discussions that happen with the API work group.

At this point, I don't think we have anyone working on doing anything
for a capabilities API in nova, nor do we have cross project agreement
on a perfect solution that will work for all projects. At the PTG in
Denver I think we just said we care less about having a perfect
guideline for all projects to have a consistent API, and more about
actually documenting the APIs that each project does have, which we do a
pretty good job of in Nova.

So I think live resize would be fine to pick up again if you're just
resizing CPU/RAM from the flavor and if we provide a policy rule to
disable it in clouds that don't want to expose that feature.

Cloudbase was originally driving it for Hyper-v so you might want to
talk with Claudiu Belu.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE&s=anotHeOxKU8HE2ff2CnYn4rwT48cG1wkINchYamlckw&e=




__
OpenStack Development Mailing 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] [doc][meeting] Doc team meeting cancelled today

[Alexandra Settle]

Hi everyone,

The documentation team meeting is cancelled today as I am unable to host this 
afternoon due to a conflict,
and Petr is travelling home from the PTG.

The next documentation team meeting will be scheduled in #openstack-meeting at 
16:00 UTC, 5 October 2017.

Petr has asked me to mention that he is most likely unable to attend the 
OpenStack Summit in Sydney.
This means we are looking for volunteers to help present our project update. Is 
anyone able to help?

Cheers,

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] [TripleO] TripleO/Ansible PTG session

[Giulio Fidente]

On 09/20/2017 07:36 PM, James Slagle wrote:
> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente  wrote:
>> On 09/18/2017 05:37 PM, James Slagle wrote:
>>> - The entire sequence and flow is driven via Mistral on the Undercloud
>>> by default. This preserves the API layer and provides a clean reusable
>>> interface for the CLI and GUI.
>>
>> I think it's worth saying that we want to move the deployment steps out
>> of heat and in ansible, not in mistral so that mistral will run the
>> workflow only once and let ansible go through the steps
>>
>> I think having the steps in mistral would be a nice option to be able to
>> rerun easily a particular deployment step from the GUI, versus having
>> them in ansible which is instead a better option for CLI users ... but
>> it looks like having them in ansible is the only option which permits us
>> to reuse the same code to deploy an undercloud because having the steps
>> in mistral would require the undercloud installation itself to depend on
>> mistral which we don't want to
>>
>> James, Dan, please comment on the above if I am wrong
> 
> That's correct. We don't want to require Mistral to install the
> Undercloud. However, I don't think that necessarily means it has to be
> a single call to ansible-playbook. We could have multiple invocations
> of ansible-playbook. Both Mistral and CLI code for installing the
> undercloud could handle that easily.
> 
> You wouldn't be able to interleave an external playbook among the
> deploy steps however. That would have to be done under a single call
> to ansible-playbook (at least how that is written now). We could
> however have hooks that could serve as integration points to call
> external playbooks after each step.

the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud

>>> - It would still be possible to run ansible-playbook directly for
>>> various use cases (dev/test/POC/demos). This preserves the quick
>>> iteration via Ansible that is often desired.
>>>
>>> - The remaining SoftwareDeployment resources in tripleo-heat-templates
>>> need to be supported by config download so that the entire
>>> configuration can be driven with Ansible, not just the deployment
>>> steps. The success criteria for this point would be to illustrate
>>> using an image that does not contain a running os-collect-config.
>>>
>>> - The ceph-ansible implementation done in Pike could be reworked to
>>> use this model. "config download" could generate playbooks that have
>>> hooks for calling external playbooks, or those hooks could be
>>> represented in the templates directly. The result would be the same
>>> either way though in that Heat would no longer be triggering a
>>> separate Mistral workflow just for ceph-ansible.
>>
>> I'd say for ceph-ansible, kubernetes and in general anything else which
>> needs to run with a standard playbook installed on the undercloud and
>> not one generated via the heat templates... these "external" services
>> usually require the inventory file to be in different format, to
>> describe the hosts to use on a per-service basis, not per-role (and I
>> mean tripleo roles here, not ansible roles obviously)
>>
>> About that, we discussed a more long term vision where the playbooks
>> (static data) needd to describe how to deploy/upgrade a given service is
>> in a separate repo (like tripleo-apb) and we "compose" from heat the
>> list of playbooks to be executed based on the roles/enabled services; in
>> this scenario we'd be much closer to what we had to do for ceph-ansible
>> and I feel like that might finally allow us merge back the ceph
>> deployment (or kubernetes deployment) process into the more general
>> approach driven by tripleo
>>
>> James, Dan, comments?
> 
> Agreed, I think this is the longer term plan in regards to using
> APB's, where everything consumed is an external playbook/role.
> 
> We definitely want to consider this plan in parallel with the POC work
> that Flavio is pulling together and make sure that they are aligned so
> that we're not constantly reworking the framework.
> 
> I've not yet had a chance to review the material he sent out this
> morning, but perhaps we could work together to update the sequence
> diagram to also have a "future" state to indicate where we are going
> and what it would look like with APB's and external paybooks.

this would be awesome, note that it isn't only ceph and kubernetes
anymore in this scenario ... I just spotted a submission for the Skydive
composable service and it us

[openstack-dev] [oslo][oslo.service] looping.RetryDecorator behavior

[Renat Akhmerov]

Hi Oslo team,

Can you please check the bug [1]?

There may be a problem with how looping.RetryDecorator works. Just stumbled on 
it in Mistral. Not sure if it’s really a bug or made by design. If it’s by 
design then maybe we need to have more accurate documentation for it.

FYI: We use this decorator in Mistral and it’s also used in Nova, [2].

[1]  https://bugs.launchpad.net/oslo.service/+bug/1718635
[2] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py

Thanks

Renat Akhmerov
@Nokia
__
OpenStack Development Mailing 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] [docs][ptls][install] Install guide vs. tutorial

[Alexandra Settle]

> For me, a tutorial is something that teaches. So after I've gone through a
> tutorial I would expect to have learned how installs work and would just 
know
> these things (with an occasional need to reference a few points) going 
forward.
>
> A guide to me is something that I know I will use whenever I need to do
> something. So for me, having an installation guide is what I would expect
> from this as every time I need to do a package based install, I am going 
to pull
> up the guide to go through it.
>
   Interesting.

So Sean has the opposite impression from Eric and I.  Yeah, that does 
make it seem like reaching a consensus will be difficult.

At that point I think consistency becomes the most important thing.


I completely agree consistency is more important, than bike shedding over the 
name :)
To be honest, it would be easier to change everything to ‘guide’ – seeing as 
all our URLs are ‘install-guide’.
But that’s the lazy in me speaking.

Industry wise – there does seem to be more of a trend towards ‘guide’ rather 
than ‘tutorial’. Although, that is at a cursory glance.

I am happy to investigate further, if this matter is of some contention to 
people?

__
OpenStack Development Mailing 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][stable] EOL tags and upper-constraints.txt in tox.ini

[Tony Breeds]

On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:

> I like the idea. I'm not sure why, if the constraints file is only used
> for the dependency installation step, we still need tox_install.sh?

Right now that isn't true, when we get something like my idea
implemented we'd still need the tox_install.sh in projects that need
services (not published on pypi) like horizon plugins or neutron stadium
projects.   Fixing that issue is a totally different discussion, one I
started at the PTG but I need to let those conversations settle and do
research on wasy to fix that.

> If
> that's just to avoid updating the URL when we create branches, I can
> live with continuing to do that step if we figure out some other way to
> minimize the open race window.

So lets check we're on the same page with the race window point.  At the
moment the process looks like:
1. projects tag RC1 and when generate a stable/series branch.
2. We generate a reviews that updates .gitreview
3. We generate a reviews that updates .tox.ini
4. time passes
5. requirements creates a stable/series branch
6. requirements thaws

Now the race is that if projects merge the patch from step 3 before step
5 they're broken (on stable/series) because there isn't a
'stable/series' in the requirements repo.  There are some additional issues
for cycle-trailing projects but nothing radically different.

Correct?

Assuming I have that right  In the new world:

0. requirements publish master.txt and series.txt
1. projects tag RC1 and when generate a stable/series branch.
2. We generate a reviews that updates .gitreview
3. We generate a reviews that updates .tox.ini
4. time passes
5. requirements creates a stable/series branch
6. requiremenst now publish series.txt, new_series.txt and master.txt
6. requirements thaws

In this scenario We've removed the race as there is a series.txt file
available befoer the project and requirements branch.

Also[1] if, right now, projects used queens.txt we wouldn't need to
update tox.ini when we branch stable/queens, but we would need to update
master.  This is a point of confusion that we'll need to document and
possible check for somewhere in our tools.

Yours Tony.

[1] This just occurred to me


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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiří Stránský]

On 21.9.2017 12:31, Giulio Fidente wrote:

On 09/20/2017 07:36 PM, James Slagle wrote:

On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente  wrote:

On 09/18/2017 05:37 PM, James Slagle wrote:

- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.


I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong


That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.


the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud



Alternatively we could do the main step loop in Ansible directly, and 
have the tasks do whatever they need to get the particular service 
deployed, from  to launching a nested ansible-playbook run if that's 
what it takes.


That way we could run the whole thing end-to-end via ansible-playbook, 
or if needed one could execute smaller bits by themselves (steps or 
nested playbook runs) -- that capability is not baked in by default, but 
i think we could make it so.


Also the interface for services would be clean and simple -- it's always 
the ansible tasks.


And Mistral-less use cases become easier to handle too (= undercloud 
installation when Mistral isn't present yet, or development envs when 
you want to tune the playbook directly without being forced to go 
through Mistral).


Logging becomes a bit more unwieldy in this scenario though, as for the 
nested ansible-playbook execution, all output would go into a task in 
the outer playbook, which would be harder to follow and the log of the 
outer playbook could be huge.


So this solution is no silver bullet, but from my current point of view 
it seems a bit less conceptually foreign than using Mistral to provide 
step loop functionality to Ansible, which should be able to handle that 
on its own.



- It would still be possible to run ansible-playbook directly for
various use cases (dev/test/POC/demos). This preserves the quick
iteration via Ansible that is often desired.

- The remaining SoftwareDeployment resources in tripleo-heat-templates
need to be supported by config download so that the entire
configuration can be driven with Ansible, not just the deployment
steps. The success criteria for this point would be to illustrate
using an image that does not contain a running os-collect-config.

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.


I'd say for ceph-ansible, kubernetes and in general anything else which
needs to run with a standard playbook installed on the undercloud and
not one generated via the heat templates... these "external" services
usually require the inventory file to be in different format, to
describe the hosts to use on a per-service basis, not per-role (and I
mean tripleo roles here, not ansible roles obviously)

About that, we discussed a more long term vision where the playbooks
(static data) needd to describe how to deploy/upgrade a given service is
in a separate repo (like tripleo-apb) and

Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary

[Thierry Carrez]

Sean Dague wrote:
> Agreed. We're already at 5 upgrade tags now?
> 
> I think honestly we're going to need a picture to explain the
> differences between them. Based on the confusion that kept seeming to
> come during discussions at the PTG, I think we need to circle around and
> figure out if there are different ways to explain this to have greater
> clarity.

In the TC/SWG room we reviewed the tags, and someone suggested that any
tag that doesn't even have one project to apply it to should probably be
removed.

That would get us rid of 3 of them: supports-accessible-upgrade,
supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+
supports-api-interoperability which has had little support so far).

They can always be resurrected when a project reaches new heights?

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [oslo][oslo.service] looping.RetryDecorator behavior

[Joshua Harlow]

It does look like is sort of a bug,

Though in all honesty I wouldn't be using oslo.service or that looping 
code in the future for doing retrying...


https://pypi.python.org/pypi/tenacity is a much better library with more 
`natural` syntax and works more as one would expect (even under threaded 
situations).


If I could of I would of never let 'loopingcall.py' become a file that 
exists, but the past is the past, ha.


Renat Akhmerov wrote:

Hi Oslo team,

Can you please check the bug [1]?

There may be a problem with how looping.RetryDecorator works. Just
stumbled on it in Mistral. Not sure if it’s really a bug or made by
design. If it’s by design then maybe we need to have more accurate
documentation for it.

FYI: We use this decorator in Mistral and it’s also used in Nova, [2].

[1] https://bugs.launchpad.net/oslo.service/+bug/1718635
[2]
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py

Thanks

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing 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][stable] publish upper-constraints.txt periodic vs post

[Matthew Thode]

On 17-09-20 14:09:15, Tony Breeds wrote:
> On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote:
> 
> > The solution I thought we decide on at the PTG is:
> >  * Add a post job to all branches that publish a constraints/$series.txt
> >to $server (I don't mind if it's releases.o.o or tarballs.o.o).
> 
> Actually we might be better to do this daily from the periodic pipeline.
> In our CI we always gate with what is in git so that wouldn't be
> impacted.  The question is do we need external consumers to be "up to
> the minute" or is a days lag acceptable?
> 
> I kinda feel like it's okay to be a little laggy.
> 
> Yours Tony.

I don't think this should be periodic, I'll try to argue the point via a
pros/cons listing.  I think we should be trying to have users use
upper-constraints via what is currently known as stable, to me that
means more often than once a day.

I'm probably a bit biased, so feel free to update :D

pros - periodic
* simple update schedule (once a day)
* easier on infra (publish just once vs up to 20-30 times a day)

cons - periodic
* point in time (once a day) does not guarantee that that point works
  while we try to ensure all projects are not impacted by changes, we
  are not perfect
* we would be making it harder for people to use upper-constraints externally
  for one thing (via longer turn around time)
* some projects may be using upper-constraints.txt from the url only

pros - post
* upper-constraints are available via published location immediately
* sets good precident for end users/devs to use it

cons - post
* both breaks and fixes quick
* more load on infra to publish (20-30 times a day)

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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Marios Andreou]

On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský  wrote:

> On 21.9.2017 12:31, Giulio Fidente wrote:
>
>> On 09/20/2017 07:36 PM, James Slagle wrote:
>>
>>> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
>>> wrote:
>>>
 On 09/18/2017 05:37 PM, James Slagle wrote:

> - The entire sequence and flow is driven via Mistral on the Undercloud
> by default. This preserves the API layer and provides a clean reusable
> interface for the CLI and GUI.
>

 I think it's worth saying that we want to move the deployment steps out
 of heat and in ansible, not in mistral so that mistral will run the
 workflow only once and let ansible go through the steps

 I think having the steps in mistral would be a nice option to be able to
 rerun easily a particular deployment step from the GUI, versus having
 them in ansible which is instead a better option for CLI users ... but
 it looks like having them in ansible is the only option which permits us
 to reuse the same code to deploy an undercloud because having the steps
 in mistral would require the undercloud installation itself to depend on
 mistral which we don't want to

 James, Dan, please comment on the above if I am wrong

>>>
>>> That's correct. We don't want to require Mistral to install the
>>> Undercloud. However, I don't think that necessarily means it has to be
>>> a single call to ansible-playbook. We could have multiple invocations
>>> of ansible-playbook. Both Mistral and CLI code for installing the
>>> undercloud could handle that easily.
>>>
>>> You wouldn't be able to interleave an external playbook among the
>>> deploy steps however. That would have to be done under a single call
>>> to ansible-playbook (at least how that is written now). We could
>>> however have hooks that could serve as integration points to call
>>> external playbooks after each step.
>>>
>>
>> the benefits of driving the steps from mistral are that then we could
>> also interleave the deployment steps and we won't need the
>> ansible-playbook hook for the "external" services:
>>
>> 1) collect the ansible tasks *and* the workflow_tasks (per step) from heat
>>
>> 2) launch the stepN deployment workflow (ansible-playbook)
>>
>> 3) execute any workflow_task defined for stepN (like ceph-ansible
>> playbook)
>>
>> 4) repeat 2 and 3 for stepN+1
>>
>> I think this would also provide a nice interface for the UI ... but then
>> we'd need mistral to be able to deploy the undercloud
>>
>>

Why not launch the _single_  deploy_steps playbook (so we have
when/conditionals with step numbers), passing in the step you want to have
executed (we can pass this in as a parameter to the mistral workflow and
pass through to the ansible-playbook invocation?), otherwise execute all
the steps. In either case whether it should be ansible handling the loop
based on a passed in parameter. 'Ansible-native' looping is currently the
case for the current deploy_steps_playbook here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335
- can we not work parameterise that playbook so that we either do loop with
the variable, or just step X?

Then for the upgrade workflow it is as above but  1.5 first launch the
upgrade_tasks_playbook  then the deploy_steps playbook for all the steps
(consider this
https://review.openstack.org/#/c/505624/3/scripts/upgrade-non-controller.sh@162
- download and run the playbooks for non-controllers in O->P upgrade
pointing this out to illustrate the workflow I have in mind). So I don't
see why we can't have mistral invoking ansible-playbook and taking
parameters like which playbook, which step etc.


>
> Alternatively we could do the main step loop in Ansible directly, and have
> the tasks do whatever they need to get the particular service deployed,
> from  to launching a nested ansible-playbook run if that's what it takes.
>


I think you can do both, I mean mistral invoking ansible-playbook and still
let ansible handle the steps with a loop. In fact that is what the current
upgrade_steps_playbook does here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L363-L365
with a loop variable 'step'. The upgrade_tasks have their 'tags: stepX'
converted to 'when: step == X' in the client here
https://github.com/openstack/python-tripleoclient/blob/4d342826d6c3db38ee88dccc92363b655b1161a5/tripleoclient/v1/overcloud_config.py#L63
- we must come up with a better solution than that; ultimately we can just
update the existing upgrade_tasks to have 'when' and the main reason for
not doing so already was not to break the heat-driven upgrade workflow but
that is going away for Q.



>
> That way we could run the whole thing end-to-end via ansible-playbook, or
> if needed one could execute smaller bits by themselves (steps or nested
> playbook runs) -- that capability is not baked in by 

Re: [openstack-dev] [requirements][stable] publish upper-constraints.txt periodic vs post

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2017-09-21 10:43:50 -0500:
> On 17-09-20 14:09:15, Tony Breeds wrote:
> > On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote:
> > 
> > > The solution I thought we decide on at the PTG is:
> > >  * Add a post job to all branches that publish a constraints/$series.txt
> > >to $server (I don't mind if it's releases.o.o or tarballs.o.o).
> > 
> > Actually we might be better to do this daily from the periodic pipeline.
> > In our CI we always gate with what is in git so that wouldn't be
> > impacted.  The question is do we need external consumers to be "up to
> > the minute" or is a days lag acceptable?
> > 
> > I kinda feel like it's okay to be a little laggy.
> > 
> > Yours Tony.
> 
> I don't think this should be periodic, I'll try to argue the point via a
> pros/cons listing.  I think we should be trying to have users use
> upper-constraints via what is currently known as stable, to me that
> means more often than once a day.
> 
> I'm probably a bit biased, so feel free to update :D
> 
> pros - periodic
> * simple update schedule (once a day)
> * easier on infra (publish just once vs up to 20-30 times a day)
> 
> cons - periodic
> * point in time (once a day) does not guarantee that that point works
>   while we try to ensure all projects are not impacted by changes, we
>   are not perfect
> * we would be making it harder for people to use upper-constraints externally
>   for one thing (via longer turn around time)
> * some projects may be using upper-constraints.txt from the url only
> 
> pros - post
> * upper-constraints are available via published location immediately
> * sets good precident for end users/devs to use it
> 
> cons - post
> * both breaks and fixes quick
> * more load on infra to publish (20-30 times a day)
> 

Another point against a periodic job is that it would be a change from
what we're doing now, where constraints are updated as soon as the git
cache is updated.

I think we should publish using a post-merge job. The job isn't
expensive, right? It's just copying some files out of git onto the
web server?

Do we really land 20-30 changes to the constraints list on an average
day?

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] [os-vif] [passthrough] [VifHostDevice]

[pranab boruah]

Hi,
We have a SRIOV capable NIC that supports OVS offload and Switchdev.
We are trying to test the VifHostDevice model on a Pike cluster. We
are running into issues. Here are the config options that we have
used:

1. In Neutron conf file: mechanism driver = ovn
2. In Nova conf file: passthrough_whitelist = {"address":":02:00.*"}
3. Created a port as vnic_type=direct and launched instances.
It gives the following error - Nova error : "No net device was found for VF"
Am I missing some other config options?

Also, how can I check the logs that are related to the os-vif library?

Let me know if further details are required.

TIA,
Pranab

__
OpenStack Development Mailing 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][stable] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> 
> > I like the idea. I'm not sure why, if the constraints file is only used
> > for the dependency installation step, we still need tox_install.sh?
> 
> Right now that isn't true, when we get something like my idea
> implemented we'd still need the tox_install.sh in projects that need
> services (not published on pypi) like horizon plugins or neutron stadium
> projects.   Fixing that issue is a totally different discussion, one I
> started at the PTG but I need to let those conversations settle and do
> research on wasy to fix that.
> 
> > If
> > that's just to avoid updating the URL when we create branches, I can
> > live with continuing to do that step if we figure out some other way to
> > minimize the open race window.
> 
> So lets check we're on the same page with the race window point.  At the
> moment the process looks like:
> 1. projects tag RC1 and when generate a stable/series branch.
> 2. We generate a reviews that updates .gitreview
> 3. We generate a reviews that updates .tox.ini
> 4. time passes
> 5. requirements creates a stable/series branch
> 6. requirements thaws
> 
> Now the race is that if projects merge the patch from step 3 before step
> 5 they're broken (on stable/series) because there isn't a
> 'stable/series' in the requirements repo.  There are some additional issues
> for cycle-trailing projects but nothing radically different.
> 
> Correct?
> 
> Assuming I have that right  In the new world:
> 
> 0. requirements publish master.txt and series.txt
> 1. projects tag RC1 and when generate a stable/series branch.
> 2. We generate a reviews that updates .gitreview
> 3. We generate a reviews that updates .tox.ini
> 4. time passes
> 5. requirements creates a stable/series branch
> 6. requiremenst now publish series.txt, new_series.txt and master.txt
> 6. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Where in the sequence do we add new_series.txt? Also between 4 and 5?

> In this scenario We've removed the race as there is a series.txt file
> available befoer the project and requirements branch.
> 
> Also[1] if, right now, projects used queens.txt we wouldn't need to
> update tox.ini when we branch stable/queens, but we would need to update
> master.  This is a point of confusion that we'll need to document and
> possible check for somewhere in our tools.
> 
> Yours Tony.
> 
> [1] This just occurred to 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] [ptg] Simplification in OpenStack

[Jeremy Stanley]

On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
[...]
> Something about common use cases and the exact mix of
> projects + configuration to get there, and testing it? Help?
[...]

Maybe you're thinking of the "constellations" suggestion? It found
its way into the TC vision statement, though the earliest mention I
can locate is in John's post to this ML thread:

http://lists.openstack.org/pipermail/openstack-dev/2017-April/115319.html

-- 
Jeremy Stanley


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

[openstack-dev] [glance] priorities for the week (09/21-09/27)

[Brian Rosmaita]

Hello Glancers,

As discussed at today's Glance weekly meeting, priorities are:

1  patches associated with Q-1 milestone targeted bugs
https://launchpad.net/glance/+milestone/queens-1

2  specs
https://review.openstack.org/#/q/status:open+project:openstack/glance-specs


Have a productive week!

__
OpenStack Development Mailing 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][stable] publish upper-constraints.txt periodic vs post

[Matthew Thode]

On 17-09-21 12:09:52, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2017-09-21 10:43:50 -0500:
> > On 17-09-20 14:09:15, Tony Breeds wrote:
> > > On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote:
> > > 
> > > > The solution I thought we decide on at the PTG is:
> > > >  * Add a post job to all branches that publish a constraints/$series.txt
> > > >to $server (I don't mind if it's releases.o.o or tarballs.o.o).
> > > 
> > > Actually we might be better to do this daily from the periodic pipeline.
> > > In our CI we always gate with what is in git so that wouldn't be
> > > impacted.  The question is do we need external consumers to be "up to
> > > the minute" or is a days lag acceptable?
> > > 
> > > I kinda feel like it's okay to be a little laggy.
> > > 
> > > Yours Tony.
> > 
> > I don't think this should be periodic, I'll try to argue the point via a
> > pros/cons listing.  I think we should be trying to have users use
> > upper-constraints via what is currently known as stable, to me that
> > means more often than once a day.
> > 
> > I'm probably a bit biased, so feel free to update :D
> > 
> > pros - periodic
> > * simple update schedule (once a day)
> > * easier on infra (publish just once vs up to 20-30 times a day)
> > 
> > cons - periodic
> > * point in time (once a day) does not guarantee that that point works
> >   while we try to ensure all projects are not impacted by changes, we
> >   are not perfect
> > * we would be making it harder for people to use upper-constraints 
> > externally
> >   for one thing (via longer turn around time)
> > * some projects may be using upper-constraints.txt from the url only
> > 
> > pros - post
> > * upper-constraints are available via published location immediately
> > * sets good precident for end users/devs to use it
> > 
> > cons - post
> > * both breaks and fixes quick
> > * more load on infra to publish (20-30 times a day)
> > 
> 
> Another point against a periodic job is that it would be a change from
> what we're doing now, where constraints are updated as soon as the git
> cache is updated.
> 
> I think we should publish using a post-merge job. The job isn't
> expensive, right? It's just copying some files out of git onto the
> web server?
> 
> Do we really land 20-30 changes to the constraints list on an average
> day?
> 
> Doug
> 

It is just copying the file, so nothing big (small file).  I'd say 20-30
changes on a very busy day (giving it the worst case).

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

Re: [openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

[Matthew Thode]

On 17-09-21 12:13:23, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> > 
> > > I like the idea. I'm not sure why, if the constraints file is only used
> > > for the dependency installation step, we still need tox_install.sh?
> > 
> > Right now that isn't true, when we get something like my idea
> > implemented we'd still need the tox_install.sh in projects that need
> > services (not published on pypi) like horizon plugins or neutron stadium
> > projects.   Fixing that issue is a totally different discussion, one I
> > started at the PTG but I need to let those conversations settle and do
> > research on wasy to fix that.
> > 
> > > If
> > > that's just to avoid updating the URL when we create branches, I can
> > > live with continuing to do that step if we figure out some other way to
> > > minimize the open race window.
> > 
> > So lets check we're on the same page with the race window point.  At the
> > moment the process looks like:
> > 1. projects tag RC1 and when generate a stable/series branch.
> > 2. We generate a reviews that updates .gitreview
> > 3. We generate a reviews that updates .tox.ini
> > 4. time passes
> > 5. requirements creates a stable/series branch
> > 6. requirements thaws
> > 
> > Now the race is that if projects merge the patch from step 3 before step
> > 5 they're broken (on stable/series) because there isn't a
> > 'stable/series' in the requirements repo.  There are some additional issues
> > for cycle-trailing projects but nothing radically different.
> > 
> > Correct?
> > 
> > Assuming I have that right  In the new world:
> > 
> > 0. requirements publish master.txt and series.txt
> > 1. projects tag RC1 and when generate a stable/series branch.
> > 2. We generate a reviews that updates .gitreview
> > 3. We generate a reviews that updates .tox.ini
> > 4. time passes
> > 5. requirements creates a stable/series branch
> > 6. requiremenst now publish series.txt, new_series.txt and master.txt
> > 6. requirements thaws
> 
> Where in that sequence do we make the change so that we're not
> publishing to series.txt from the new stable branch in requirements and
> from master in requirements? Between step 4 and 5? Or is the job smart
> enough to not do that?
> 
> Where in the sequence do we add new_series.txt? Also between 4 and 5?
> 

That step of switching from publishing series.txt to new-series.txt
happens in step 6.  Step 6 should be dependant on step 5's
patchset/review.  The requirements freeze itself hapens some time during
step 4 I think.

> > In this scenario We've removed the race as there is a series.txt file
> > available befoer the project and requirements branch.
> > 
> > Also[1] if, right now, projects used queens.txt we wouldn't need to
> > update tox.ini when we branch stable/queens, but we would need to update
> > master.  This is a point of confusion that we'll need to document and
> > possible check for somewhere in our tools.
> > 
> > Yours Tony.
> > 
> > [1] This just occurred to 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

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

Re: [openstack-dev] [infra] Unable to add member to Zun core team

[Jeremy Stanley]

On 2017-09-21 02:55:13 + (+), Hongbin Lu wrote:
> I tried to add Kien Nguyen
> kie...@vn.fujitsu.com to the Zun's
> core team [1], but gerrit prevented me to do that. Attached file
> showed the error. Could anyone provide suggestion for this?

Kien has multiple accounts (Ids are 22406 and 26112) in Gerrit
sharing the same E-mail address. It looks like this may be related
to switching Launchpad SSO between a gmail.com address and a
vn.fujitsu.com address around June 1 of this year. The newer account
appears to have a username and SSH key, suggesting it's now being
used to sign in and push changes, so I've left that one active and
marked the older account inactive which should clear the error; go
ahead and try again.

Unfortunately, Gerrit lacks a feature for merging accounts and
account history/settings, so if Kien experiences any complications
from this adjustment, have them E-mail the
openstack-in...@lists.openstack.org mailing list or find us in the
#openstack-infra channel on the Freenode IRC network. Thanks!
-- 
Jeremy Stanley


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

[openstack-dev] Fwd: [k8s][deployment][kolla-kubernetes][magnum][kuryr][qa][api] Proposal for SIG-K8s

[Chris Hoge]

In preparation for the Sydney Forum, I’ve created a brainstorming
etherpad for forum topics. Please contribute topics as you see fit,
and from there we can start making some submissions.

https://etherpad.openstack.org/p/sig-k8s-sydney-forum-topics 

https://wiki.openstack.org/wiki/Forum/Sydney2017 


PTG got me a little behind on this.

Thanks,
Chris

> Begin forwarded message:
> 
> From: Chris Hoge 
> Subject: [openstack-dev] 
> [k8s][deployment][kolla-kubernetes][magnum][kuryr][qa][api] Proposal for 
> SIG-K8s
> Date: September 14, 2017 at 9:23:22 AM PDT
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Reply-To: "OpenStack Development Mailing List \(not for usage questions\)" 
> 
> 
> This Friday, September 15 at the PTG we will be hosting an organizational
> meeting for SIG-K8s. More information on the proposal, meeting time, and
> remote attendance is in the openstack-sigs mailing list [1].
> 
> Thanks,
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-sigs/2017-September/51.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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][nova][mogan] How to show respect to the original authors?

[Mike Perez]

On 15:56 Sep 20, Flavio Percoco wrote:
> On 20/09/17 12:21 +, Jeremy Stanley wrote:
> > On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> > [...]
> > > please indicate which file from Nova, so if anyone wanted to cross
> > > check for fixes etc can go look in Nova
> > [...]
> > 
> > While the opportunity has probably passed in this case, the ideal
> > method is to start with a Git fork of the original as your seed
> > project (perhaps with history pruned to just the files you're
> > reusing via git filter-branch or similar). This way the complete
> > change history of the files in question is preserved for future
> > inspection.
> 
> If it's not too late, I would definitely recommend going with a fork, fwiw.
> 
> Flavio
> 
> --
> @flaper87
> Flavio Percoco

+1 please fork instead.

-- 
Mike Perez


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

Re: [openstack-dev] [infra] Unable to add member to Zun core team

[Kiên Nguyễn Tuấn]

Hi Infra Team,

I'm Kien Nguyen . Actually, the older account with
id 22406 is my current account and the newer is not.

Therefore, please mark the newer account (26112) as inactive and re-active
the 22406 account. Sorry for this inconvenient.

Best regards,
Kien Nguyen

2017-09-21 23:28 GMT+07:00 Jeremy Stanley :

> On 2017-09-21 02:55:13 + (+), Hongbin Lu wrote:
> > I tried to add Kien Nguyen
> > kie...@vn.fujitsu.com to the Zun's
> > core team [1], but gerrit prevented me to do that. Attached file
> > showed the error. Could anyone provide suggestion for this?
>
> Kien has multiple accounts (Ids are 22406 and 26112) in Gerrit
> sharing the same E-mail address. It looks like this may be related
> to switching Launchpad SSO between a gmail.com address and a
> vn.fujitsu.com address around June 1 of this year. The newer account
> appears to have a username and SSH key, suggesting it's now being
> used to sign in and push changes, so I've left that one active and
> marked the older account inactive which should clear the error; go
> ahead and try again.
>
> Unfortunately, Gerrit lacks a feature for merging accounts and
> account history/settings, so if Kien experiences any complications
> from this adjustment, have them E-mail the
> openstack-in...@lists.openstack.org mailing list or find us in the
> #openstack-infra channel on the Freenode IRC network. Thanks!
> --
> 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-dev] Janney 2.0 "Data Protection in OpenStack" Summary Presentation

[Farr, Kaitlin M.]

Hi everyone,

I will be presenting a recap of the "Data Protection in OpenStack" presentation 
from IEEE CLOUD on Monday, September 25th at 4 PM in Central Spark.  The 
OpenStack team wrote the paper, and the funding came from the Janney 2.0 
"Engage" awards.

https://aplweb.jhuapl.edu/news/Pages/JanneyTalks_KaitlineFarr.aspx

Thanks!

Kaitlin

__
OpenStack Development Mailing 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] Update Ping List for Weekly Meeting ...

[Jay S Bryant]

All,

Just wanted to communicate the fact that I have cleaned out the ping 
list for our weekly team meeting.  I shared this in yesterday's team 
meeting but also wanted to communicate it here for those who missed the 
meeting.


The new list is in our new meeting agenda etherpad [1] .  If you wish to 
be pinged at the start of the weekly meeting, please add your name back 
to the etherpad.


Thanks!

Jay

[1] https://etherpad.openstack.org/p/cinder-queens-meeting-agendas


__
OpenStack Development Mailing 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] [os-vif] [passthrough] [VifHostDevice]

[Mooney, Sean K]

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Thursday, September 21, 2017 5:12 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [os-vif] [passthrough] [VifHostDevice]
> 
> Hi,
> We have a SRIOV capable NIC that supports OVS offload and Switchdev.
> We are trying to test the VifHostDevice model on a Pike cluster. We are
> running into issues. Here are the config options that we have
> used:
> 
> 1. In Neutron conf file: mechanism driver = ovn 
[Mooney, Sean K] looking at the networking-ovn ml2 dirver vnic type direct is 
not supported
https://github.com/openstack/networking-ovn/blob/f5fe5e3c623a2a65ee78ec28b053d8e72060c13d/networking_ovn/ml2/mech_driver.py#L112
the hardware offload support for melonox nics is only supported with the 
openvswitch or odl ml2 dirvers
netronome smartnics require the use of the agilio ovs ml2 dirver which supports
dirct and virtio forwarder mode
https://github.com/Netronome/agilio-ovs-openstack-plugin/blob/master/networking_netronome/plugins/ml2/drivers/agilio_ovs/mech_driver/mech_agilio_ovs.py#L46-L47

if you wish to use ovn you will need to modify the ovn ml2 dirver to add 
vnic_type direct to the supported vnictypes.

>2. In Nova conf file:
> passthrough_whitelist = {"address":":02:00.*"} 3. Created a port as
> vnic_type=direct and launched instances.
> It gives the following error - Nova error : "No net device was found
> for VF"
> Am I missing some other config options?
[Mooney, Sean K] no but as I mentioned above ovn is not currently supported.
I belive you should have a log message in the neutron server log also as when 
neutron calls
The the networking-ovn ml2 driver here
https://github.com/openstack/neutron/blob/433d5a03534c4f30fdf3b864d11dea527e9b6f91/neutron/plugins/ml2/managers.py#L782
we simply retrun on line 502 here after logging.
https://github.com/openstack/networking-ovn/blob/f5fe5e3c623a2a65ee78ec28b053d8e72060c13d/networking_ovn/ml2/mech_driver.py#L502
if you only have the ovn ml2 driver enabled you should set the prot with 
vif_type_binding_failed howver if you have
the sriovnicagent also enable it may be masking the isses as 
https://github.com/openstack/neutron/blob/433d5a03534c4f30fdf3b864d11dea527e9b6f91/neutron/plugins/ml2/managers.py#L776
will continue to try the other dirvers.

Assuming ovn in the only enabled mech driver i belive this should result in the 
vif_type being set to VIF_TYPE_BINDING_FAILED as
https://github.com/openstack/neutron/blob/433d5a03534c4f30fdf3b864d11dea527e9b6f91/neutron/plugins/ml2/managers.py#L748
will not return anyting so we should execute 
https://github.com/openstack/neutron/blob/433d5a03534c4f30fdf3b864d11dea527e9b6f91/neutron/plugins/ml2/managers.py#L750-L757
you should be able to configm this by doing a port show and/or checking the 
neutron server log.

> 
> Also, how can I check the logs that are related to the os-vif library?
[Mooney, Sean K] the logs are present in the n-cpu log as os-vif executes with 
the nova compute agent.
> 
> Let me know if further details are required.
> 
> TIA,
> Pranab
> 
> ___
> ___
> OpenStack Development Mailing 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] [skip-level-upgrades][fast-forward-upgrades] PTG summary

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-09-21 17:10:52 +0200:
> Sean Dague wrote:
> > Agreed. We're already at 5 upgrade tags now?
> > 
> > I think honestly we're going to need a picture to explain the
> > differences between them. Based on the confusion that kept seeming to
> > come during discussions at the PTG, I think we need to circle around and
> > figure out if there are different ways to explain this to have greater
> > clarity.
> 
> In the TC/SWG room we reviewed the tags, and someone suggested that any
> tag that doesn't even have one project to apply it to should probably be
> removed.
> 
> That would get us rid of 3 of them: supports-accessible-upgrade,
> supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+
> supports-api-interoperability which has had little support so far).
> 
> They can always be resurrected when a project reaches new heights?
> 

On the other hand, some of those were meant to be aspirational, so not
documenting them may mean no one is thinking about them at all.

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] TripleO/Ansible PTG session

[Jiří Stránský]

On 21.9.2017 18:04, Marios Andreou wrote:

On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský  wrote:


On 21.9.2017 12:31, Giulio Fidente wrote:


On 09/20/2017 07:36 PM, James Slagle wrote:


On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
wrote:


On 09/18/2017 05:37 PM, James Slagle wrote:


- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.



I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong



That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.



the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible
playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud




Why not launch the _single_  deploy_steps playbook (so we have
when/conditionals with step numbers), passing in the step you want to have
executed (we can pass this in as a parameter to the mistral workflow and
pass through to the ansible-playbook invocation?), otherwise execute all
the steps.


+1 that's the sort of thing i meant by "it's not baked in by default but 
we could make it so". We could even give it a list of steps like 
`tripleo_run_steps: [4, 5, 6]`.



In either case whether it should be ansible handling the loop
based on a passed in parameter.
'Ansible-native' looping is currently the
case for the current deploy_steps_playbook here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335
- can we not work parameterise that playbook so that we either do loop with
the variable, or just step X?

Then for the upgrade workflow it is as above but  1.5 first launch the
upgrade_tasks_playbook  then the deploy_steps playbook for all the steps
(consider this
https://review.openstack.org/#/c/505624/3/scripts/upgrade-non-controller.sh@162
- download and run the playbooks for non-controllers in O->P upgrade
pointing this out to illustrate the workflow I have in mind). So I don't
see why we can't have mistral invoking ansible-playbook and taking
parameters like which playbook, which step etc.




Alternatively we could do the main step loop in Ansible directly, and have
the tasks do whatever they need to get the particular service deployed,
from  to launching a nested ansible-playbook run if that's what it takes.




I think you can do both, I mean mistral invoking ansible-playbook and still
let ansible handle the steps with a loop.


+1 exactly. FWIW i'm totally on board with wrapping everything in 
Mistral on the outermost level, as that's required for UI. I'm just not 
keen on having Mistral enter the process in between each step and drive 
the step loop.



In fact that is what the current
upgrade_steps_playbook does here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L363-L365
with a loop variable 'step'. The upgrade_tasks have their 'tags: stepX'
converted to 'when: step == X' in the client here
https://github.com/openstack/python-tripleoclient/blob/4d342826d6c3db38ee88dccc92363b655b1161a5/tripleoclient/v1/overcloud_config.py#L63
- we must come up with a better solution than that; ultimately we can just
update the existing upgrade_tasks to have 'when' and the main reason for
not doing so already was not to break the heat-driven upgrade workflow 

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
> On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
> [...]
> > Something about common use cases and the exact mix of
> > projects + configuration to get there, and testing it? Help?
> [...]
> 
> Maybe you're thinking of the "constellations" suggestion? It found
> its way into the TC vision statement, though the earliest mention I
> can locate is in John's post to this ML thread:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115319.html
> 

Yes, constellations. 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

[openstack-dev] [all][api] POST /api-sig/news

[michael mccune]

Greetings OpenStack community,

This week's meeting was primarily focused on reviewing the discussions 
and plans that were proposed at the PTG. We also merged one new 
guideline which was frozen prior to the PTG.


For a review of PTG activity, please see the etherpad[4]

One of the big takeaways from the PTG for the API-SIG was how the SIG is 
perceived by the user community. We had not realized that the user 
community considered us 'dev-only', which was never our intent. We 
agreed that it is in the best interest of all to become more inclusive 
of SDK and user-related concerns. This spurred a good deal of 
conversation at the PTG, and the SIG is starting to make plans about how 
we can best meet the user community's needs, and include their concerns 
in our guidance.


Another big topic from the PTG was a discussion around capabilities and 
how they should be included in OpenStack APIs. There are no concrete 
plans yet, but the conversation in Denver exposed many issues related to 
the techinical and social sides of creating a defining capabilities 
guideline.


Microversions also reared their head in the form of a long discussion 
about how SDK developers and users are consuming microversions at a very 
granular level. This discussion opened many surprised eyes as we learned 
how different SDK platforms deal with microversions, and what exactly 
are the best practices. We agreed that it is generally good for an SDK 
to shield its users from the details of microversions, but to allow 
power users to access them if they care to.


During the Queens cycle you can expect the API-SIG to be taking up these 
issues from the PTG, and become a more open forum for not only API 
consumers, but also to the wider SDK community.


# Newly Published Guidelines

* Explain, simply, why extensions are bad
  https://review.openstack.org/#/c/491611/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://etherpad.openstack.org/p/api-ptg-queens

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
OpenStack Development Mailing 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] TripleO/Ansible PTG session

[James Slagle]

On Thu, Sep 21, 2017 at 11:53 AM, Jiří Stránský  wrote:
> On 21.9.2017 18:04, Marios Andreou wrote:
>>
>> On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský  wrote:
>>
>>> On 21.9.2017 12:31, Giulio Fidente wrote:
>>>
 On 09/20/2017 07:36 PM, James Slagle wrote:

> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
> wrote:
>
>> On 09/18/2017 05:37 PM, James Slagle wrote:
>>
>>> - The entire sequence and flow is driven via Mistral on the
>>> Undercloud
>>> by default. This preserves the API layer and provides a clean
>>> reusable
>>> interface for the CLI and GUI.
>>>
>>
>> I think it's worth saying that we want to move the deployment steps
>> out
>> of heat and in ansible, not in mistral so that mistral will run the
>> workflow only once and let ansible go through the steps
>>
>> I think having the steps in mistral would be a nice option to be able
>> to
>> rerun easily a particular deployment step from the GUI, versus having
>> them in ansible which is instead a better option for CLI users ... but
>> it looks like having them in ansible is the only option which permits
>> us
>> to reuse the same code to deploy an undercloud because having the
>> steps
>> in mistral would require the undercloud installation itself to depend
>> on
>> mistral which we don't want to
>>
>> James, Dan, please comment on the above if I am wrong
>>
>
> That's correct. We don't want to require Mistral to install the
> Undercloud. However, I don't think that necessarily means it has to be
> a single call to ansible-playbook. We could have multiple invocations
> of ansible-playbook. Both Mistral and CLI code for installing the
> undercloud could handle that easily.
>
> You wouldn't be able to interleave an external playbook among the
> deploy steps however. That would have to be done under a single call
> to ansible-playbook (at least how that is written now). We could
> however have hooks that could serve as integration points to call
> external playbooks after each step.
>

 the benefits of driving the steps from mistral are that then we could
 also interleave the deployment steps and we won't need the
 ansible-playbook hook for the "external" services:

 1) collect the ansible tasks *and* the workflow_tasks (per step) from
 heat

 2) launch the stepN deployment workflow (ansible-playbook)

 3) execute any workflow_task defined for stepN (like ceph-ansible
 playbook)

 4) repeat 2 and 3 for stepN+1

 I think this would also provide a nice interface for the UI ... but then
 we'd need mistral to be able to deploy the undercloud


>>
>> Why not launch the _single_  deploy_steps playbook (so we have
>> when/conditionals with step numbers), passing in the step you want to have
>> executed (we can pass this in as a parameter to the mistral workflow and
>> pass through to the ansible-playbook invocation?), otherwise execute all
>> the steps.
>
>
> +1 that's the sort of thing i meant by "it's not baked in by default but we
> could make it so". We could even give it a list of steps like
> `tripleo_run_steps: [4, 5, 6]`.

Agreed. We can parameterize as needed so that it could be driven via
Mistral for finer grained control for the API/UI or by a single
ansible-playbook directly.




-- 
-- 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] [skip-level-upgrades][fast-forward-upgrades] PTG summary

[Jeremy Stanley]

On 2017-09-21 13:29:53 -0400 (-0400), Doug Hellmann wrote:
[...]
> On the other hand, some of those were meant to be aspirational, so
> not documenting them may mean no one is thinking about them at
> all.

Previous tags were added to document existing state/practices and
came with projects already meeting their criteria. We've got other
mechanisms for identifying features to which software can aspire...
adding "vaporware" tags in an attempt to feel out what a taxonomy of
upgrade models *might* look like seems more likely to confuse
consumers of that data than provide useful information.
-- 
Jeremy Stanley


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

[openstack-dev] Sydney Forum Topic Submission

[Shamail Tahir]

Hi,

We have made it to the next stage of the topic selection process for the
Forum in Sydney!

At the Forum the entire OpenStack community (users and developers) gathers
to brainstorm the requirements for the next release, gather feedback on the
past version and have strategic discussions that go beyond just one release
cycle. The Sydney Forum is the start of the Rocky release cycle. Please
prepare session ideas with feedback from the Pike release in mind.

Our submission tool is now open for you to submit abstracts for the most
popular sessions that came out of your brainstorming.

Ask all session leaders to submit their abstracts at:
http://forumtopics.openstack.org/

before *11:59PM UTC on Friday September 29th*!

We are looking for a good mix of project-specific, cross-project or
strategic/whole-of-community discussions, and sessions that emphasize
collaboration between users and developers are most welcome!

We assume that anything submitted to the Forum Topics Tool has achieved a
good amount of discussion and consensus that it's a worthwhile topic. After
submissions close, a team of representatives from the User Committee, the
Technical Committee, and Foundation staff will take the sessions proposed
by the community and fill out the schedule.

You can expect the draft schedule to be released on October 9th, 2017.

Further details about the Forum can be found at:
https://wiki.openstack.org/wiki/Forum

Regards,
User Committee/Technical Committee
__
OpenStack Development Mailing 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] [vitrage] Extending Topology

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Usman,

Great to hear back from you ☺

You are more than welcome to join our efforts. You can look at the list of 
blueprints[1], suggest new ones, implement existing, or solve bugs[2]. Whatever 
you chose, we will be happy to assist.

The ways to contact Vitrage developers are here in the mailing list, or on 
#openstack-vitrage IRC channel. In addition, we meet every Wednesday at 8:00 
UTC on #openstack-meeting-4, so you can join and discuss whatever topic you are 
interested in.

[1] https://blueprints.launchpad.net/vitrage
[2] https://bugs.launchpad.net/vitrage

Best Regards,
Ifat.

From: Muhammad Usman 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 21 September 2017 at 4:59
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [vitrage] Extending Topology

Dear Ifat,

Usman is here. Previously, I contacted you for contributing to OpenStack 
Vitrage project but could not  follow up with you for sometime due to various 
reasons.

However, to get actively involved in OpenStack project, I have decided to join 
OpenStack Summit in Sydney.

Also, based on my previous experience withe Vitrage project that is already in 
shape, so its not easy to propose new ideas.

Therefore, a better way to start contributing to development side with already 
proposed and on-going development.

--

Regards

Muhammad Usman
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com
+92 (323) 5599 068


__
OpenStack Development Mailing 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] [infra] Unable to add member to Zun core team

[Jeremy Stanley]

On 2017-09-22 00:16:13 +0700 (+0700), Kiên Nguyễn Tuấn wrote:
> I'm Kien Nguyen . Actually, the older
> account with id 22406 is my current account and the newer is not.
> 
> Therefore, please mark the newer account (26112) as inactive and
> re-active the 22406 account.

Done, please double-check to make sure things are working the way
you expect once more.

> Sorry for this inconvenient.

My apologies for bounding forth and assuming I could tell which
account you were actually using!
-- 
Jeremy Stanley


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

[openstack-dev] [nova] Forum topics brainstorming

[Matt Riedemann]

So this shouldn't be news now that I've read back through a few emails 
in the mailing list (I've been distracted with the Pike release, PTG 
planning, etc) [1][2][3] but we have until Sept 29 to come up with 
whatever forum sessions we want to propose.


There is already an etherpad for Nova [4].

The list of proposed topics is here [5]. The good news is we're not the 
last ones to this party.


So let's start throwing things on the etherpad and figure out what we 
want to propose as forum session topis. If memory serves me, in Pike we 
were pretty liberal in what we proposed.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121783.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122143.html
[3] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122454.html

[4] https://etherpad.openstack.org/p/SYD-nova-brainstorming
[5] http://forumtopics.openstack.org/

--

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] [tc][nova][mogan] How to show respect to the original authors?

[Matt Riedemann]

On 9/21/2017 11:55 AM, Mike Perez wrote:

On 15:56 Sep 20, Flavio Percoco wrote:

On 20/09/17 12:21 +, Jeremy Stanley wrote:

On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
[...]

please indicate which file from Nova, so if anyone wanted to cross
check for fixes etc can go look in Nova

[...]

While the opportunity has probably passed in this case, the ideal
method is to start with a Git fork of the original as your seed
project (perhaps with history pruned to just the files you're
reusing via git filter-branch or similar). This way the complete
change history of the files in question is preserved for future
inspection.


If it's not too late, I would definitely recommend going with a fork, fwiw.

Flavio

--
@flaper87
Flavio Percoco


+1 please fork instead.



__
OpenStack Development Mailing 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'm pretty sure this ship has sailed. Mogan has been around since before 
the PTG in Atlanta.


--

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] [Openstack-operators] [nova] Is there any reason to exclude originally failed build hosts during live migration?

[Matt Riedemann]

On 9/21/2017 6:17 AM, Saverio Proto wrote:

Why the change is called:
Ignore original retried hosts when live migrating
?

Isn't it implementing the opposite ? Dont Ignore ?


Heh, you're right. I'll fix.

Beyond that, any feedback on the actual intent here?

--

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] About live-resize spec

[Matt Riedemann]

On 9/21/2017 3:13 AM, Claudiu Belu wrote:
I don't know how soon the capabilities thing can become a real thing, 
but IMO, we can go with Matt's suggestion of disabling the feature by 
default through policy.


I wouldn't hold my breath on a capabilities API, so I think a policy 
rule is what we'll need to do for this.


--

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] PDFs for project-specific docs with unified doc builds

[Ian Y. Choi]

Hello,

"Build PDF docs from rst-based guide documents" [1] was implemented in Ocata
cycle, and I have heard that there were a small conversation at the 
Denver PTG

regarding getting PDFs for project-specific docs setup to help translations.

In my opinion, it would be a nice idea to extend [1] to project-specific
docs with unified doc builds. It seems that unified doc builds have been
much enhanced with [2]. Now I think having PDF build functionalities in 
unified

doc builds would be a way to easily have PDFs for project-specific docs.

Would someone have any idea on this or help it with some good pointers?


With many thanks,

/Ian

[1] 
http://specs.openstack.org/openstack/docs-specs/specs/ocata/build-pdf-from-rst-guides.html
[2] 
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html


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

Re: [openstack-dev] [neutron][fwaas] Proposal to change the time for Firewall-as-a-Service Team Meeting

[Furukawa, Yushiro]

Hi,

I’m sorry I’m late.  I just voted it.

Thanks,


Yushiro Furukawa

From: reedip banerjee [mailto:reedi...@gmail.com]
Sent: Tuesday, September 19, 2017 11:54 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron][fwaas] Proposal to change the time for 
Firewall-as-a-Service Team Meeting

Dear All,
Due to clashes of the Firewal-as-a-Service team meetup with the bi-weekly 
Neutron and Common-Classifier meeting, it was suggested in today's meetup to 
change the timing.

https://doodle.com/poll/c5rgth6y54bpvncu is the Link to vote for the day when 
the meeting can be held.

--
Thanks and Regards,
Reedip Banerjee
IRC: reedip



__
OpenStack Development Mailing 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] [infra] Unable to add member to Zun core team

[Kiên Nguyễn Tuấn]

Hi Jeremy,

No problem at all. I just checked it and everything seems work well now.
I will tell Hongbin Lu to try again.

Huge thanks,

Kien Nguyen

2017-09-22 3:59 GMT+07:00 Jeremy Stanley :

> On 2017-09-22 00:16:13 +0700 (+0700), Kiên Nguyễn Tuấn wrote:
> > I'm Kien Nguyen . Actually, the older
> > account with id 22406 is my current account and the newer is not.
> >
> > Therefore, please mark the newer account (26112) as inactive and
> > re-active the 22406 account.
>
> Done, please double-check to make sure things are working the way
> you expect once more.
>
> > Sorry for this inconvenient.
>
> My apologies for bounding forth and assuming I could tell which
> account you were actually using!
> --
> 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

Re: [openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

[Tony Breeds]

On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> > 
> > > I like the idea. I'm not sure why, if the constraints file is only used
> > > for the dependency installation step, we still need tox_install.sh?
> > 
> > Right now that isn't true, when we get something like my idea
> > implemented we'd still need the tox_install.sh in projects that need
> > services (not published on pypi) like horizon plugins or neutron stadium
> > projects.   Fixing that issue is a totally different discussion, one I
> > started at the PTG but I need to let those conversations settle and do
> > research on wasy to fix that.
> > 
> > > If
> > > that's just to avoid updating the URL when we create branches, I can
> > > live with continuing to do that step if we figure out some other way to
> > > minimize the open race window.
> > 
> > So lets check we're on the same page with the race window point.  At the
> > moment the process looks like:
> > 1. projects tag RC1 and when generate a stable/series branch.
> > 2. We generate a reviews that updates .gitreview
> > 3. We generate a reviews that updates .tox.ini
> > 4. time passes
> > 5. requirements creates a stable/series branch
> > 6. requirements thaws
> > 
> > Now the race is that if projects merge the patch from step 3 before step
> > 5 they're broken (on stable/series) because there isn't a
> > 'stable/series' in the requirements repo.  There are some additional issues
> > for cycle-trailing projects but nothing radically different.
> > 
> > Correct?
> > 
> > Assuming I have that right  In the new world:
> > 
> > 0. requirements publish master.txt and series.txt
> > 1. projects tag RC1 and when generate a stable/series branch.
> > 2. We generate a reviews that updates .gitreview
> > 3. We generate a reviews that updates .tox.ini
> > 4. time passes
> > 5. requirements creates a stable/series branch
> > 6. requiremenst now publish series.txt, new_series.txt and master.txt
> > 6. requirements thaws
> 
> Where in that sequence do we make the change so that we're not
> publishing to series.txt from the new stable branch in requirements and
> from master in requirements? Between step 4 and 5? Or is the job smart
> enough to not do that?

Right now the job is dumb, but yes we'd teach the job to detect that's
it's a stable branch and only publish it's series branch.  We also teach
the job to not publish to $series.txt if that stable branch exists.

So I think the publish job looks like:

---
# preamble
# typed directly into email so be warned ;P
# We probably want to check if ZUUL_BRANCH is the correct variable to
# use.
case "$ZUUL_BRANCH" in
stable/*)
series=$(basename "$ZUUL_BRANCH")
git show origin/$ZUUL_BRANCH:upper-constraints.txt > 
publish/constraints/upper/${series}.txt
;;
master)
for series in queens master ; do
if ! git rev-parse origin/stable/${series} ; then
git show origin/master:upper-constraints.txt > 
publish/constraints/upper/${series}.txt
fi
done
;;
esac
# postample
---

So using the queens release as an example:

Jan 22 - Jan 26 R-5 Requirements freeze
NOTES: openstack/requirements (master) publishes 
{queens,master}.txt
Jan 29 - Feb 02 R-4  
Feb 05 - Feb 09 R-3 RC1 target week
ACTIONS: Projects create stable/queens branches
ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS 
changes
Feb 12 - Feb 16 R-2
ACTIONS: Projects create stable/queens branch for 
openstack/requirements
ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS 
changes
ACTIONS: Make sure master publishes {rocky,master}.txt
 (optionally add the S release at this point, it 
doesn't hurt)
Feb 19 - Feb 23 R-1 
Feb 26 - Mar 02 R+0 Queens release
Mar 05 - Mar 09 R+1  
Mar 12 - Mar 16 R+2 Queens cycle-trailing release deadline

There's a whole other side issue about how long requirements is frozen
for.  Ignoring that do you think the above process will remove the race,
and mean that EOL branches can possibly continue to run tests?


Yours Tony.


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

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann  wrote:

> On 9/21/2017 11:55 AM, Mike Perez wrote:
>
>> On 15:56 Sep 20, Flavio Percoco wrote:
>>
>>> On 20/09/17 12:21 +, Jeremy Stanley wrote:
>>>
 On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
 [...]

> please indicate which file from Nova, so if anyone wanted to cross
> check for fixes etc can go look in Nova
>
 [...]

 While the opportunity has probably passed in this case, the ideal
 method is to start with a Git fork of the original as your seed
 project (perhaps with history pruned to just the files you're
 reusing via git filter-branch or similar). This way the complete
 change history of the files in question is preserved for future
 inspection.

>>>
>>> If it's not too late, I would definitely recommend going with a fork,
>>> fwiw.
>>>
>>> Flavio
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>>
>>
>> +1 please fork instead.
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> I'm pretty sure this ship has sailed. Mogan has been around since before
> the PTG in Atlanta.
>
> --
>
> 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
>

Yes, we are way past that, and there are already 1000+ commits since Mogan
created,

-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

Thanks John Dickinson, we can follow Swift's way but as Michael Still
mentioned seems listing all authors isn't practical.

On Thu, Sep 21, 2017 at 5:43 AM, John Dickinson  wrote:

>
>
> On 20 Sep 2017, at 9:25, Michael Still wrote:
>
> > Dims, I'm not sure that's actually possible though. Many of these files
> > have been through rewrites and developed over a large number of years.
> > Listing all authors isn't practical.
> >
> > Given the horse has bolted on forking these files, I feel like a comment
> > acknowledging the original source file is probably sufficient.
>
> In Swift's repo, we acknowledge the original authors in a section of the
> AUTHORS file
>
> https://github.com/openstack/swift/blob/master/AUTHORS
>
> --John
>
>
>
> >
> > What is concerning to me is that some of these files are part of the
> "ABI"
> > of nova, and if mogan diverges from that then I think we're going to see
> > user complaints in the future. Specifically configdrive, and metadata
> seem
> > like examples of this. I don't want to see us end up in another "managed
> > cut and paste" like early oslo where nova continues to develop these and
> > mogan doesn't notice the changes.
> >
> > I'm not sure how we resolve that. One option would be to refactor these
> > files into a shared library.
> >
> > Michael
> >
> >
> >
> >
> > On Wed, Sep 20, 2017 at 5:51 AM, Davanum Srinivas 
> wrote:
> >
> >> Zhenguo,
> >>
> >> Thanks for bringing this up.
> >>
> >> For #1, yes please indicate which file from Nova, so if anyone wanted
> >> to cross check for fixes etc can go look in Nova
> >> For #2, When you pick up a commit from Nova, please make sure the
> >> commit message in Mogan has the following
> >>* The gerrit change id(s) of the original commit, so folks can
> >> easily go find the original commit in gerritt
> >>* Add "Co-Authored-By:" tags for each author in the original commit
> >> so they get credit
> >>
> >> Also, Please make sure you do not alter any copyright or license
> >> related information in the header when you first copy a file from
> >> another project.
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Wed, Sep 20, 2017 at 4:20 AM, Zhenguo Niu 
> >> wrote:
> >>> Hi all,
> >>>
> >>> I'm from Mogan team, we copied some codes/frameworks from Nova since we
> >> want
> >>> to be a Nova with a bare metal specific API.
> >>> About why reinventing the wheel, you can find more informations here
> [1].
> >>>
> >>> I would like to know what's the decent way to show our respect to the
> >>> original authors we copied from.
> >>>
> >>> After discussing with the team, we plan to do some improvements as
> below:
> >>>
> >>> 1. Adds some comments to the beginning of such files to indicate that
> >> they
> >>> leveraged the implementation of Nova.
> >>>
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> baremetal/ironic/driver.py#L19
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> console/websocketproxy.py#L17-L18
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> consoleauth/manager.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> engine/configdrive.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> engine/metadata.py#L18
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> network/api.py#L18
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/aggregate.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/keypair.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/server_fault.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/server_group.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> scheduler/client/report.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> scheduler/filter_scheduler.py#L17
> >>>
> >>> 2. For the changes we follows what nova changed, should reference to
> the
> >>> original authors in the commit messages.
> >>>
> >>>
> >>> Please let me know if there are something else we need to do or there
> are
> >>> already some existing principles we can follow, thanks!
> >>>
> >>>
> >>>
> >>> [1] https://wiki.openstack.org/wiki/Mogan
> >>>
> >>>
> >>> --
> >>> Best Regards,
> >>> Zhenguo Niu
> >>>
> >>> 
> >> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> >> unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Davanum Srinivas :: https://twitter.com/dims
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

On Wed, Sep 20, 2017 at 7:51 PM, Davanum Srinivas  wrote:

> Zhenguo,
>
> Thanks for bringing this up.
>
> For #1, yes please indicate which file from Nova, so if anyone wanted
> to cross check for fixes etc can go look in Nova
> For #2, When you pick up a commit from Nova, please make sure the
> commit message in Mogan has the following
>* The gerrit change id(s) of the original commit, so folks can
> easily go find the original commit in gerritt
>* Add "Co-Authored-By:" tags for each author in the original commit
> so they get credit
>
> Also, Please make sure you do not alter any copyright or license
> related information in the header when you first copy a file from
> another project.
>

Sure, we will keep the original copyright and license in the header.


>
> Thanks,
> Dims
>
> On Wed, Sep 20, 2017 at 4:20 AM, Zhenguo Niu 
> wrote:
> > Hi all,
> >
> > I'm from Mogan team, we copied some codes/frameworks from Nova since we
> want
> > to be a Nova with a bare metal specific API.
> > About why reinventing the wheel, you can find more informations here [1].
> >
> > I would like to know what's the decent way to show our respect to the
> > original authors we copied from.
> >
> > After discussing with the team, we plan to do some improvements as below:
> >
> > 1. Adds some comments to the beginning of such files to indicate that
> they
> > leveraged the implementation of Nova.
> >
> > https://github.com/openstack/mogan/blob/master/mogan/
> baremetal/ironic/driver.py#L19
> > https://github.com/openstack/mogan/blob/master/mogan/
> console/websocketproxy.py#L17-L18
> > https://github.com/openstack/mogan/blob/master/mogan/
> consoleauth/manager.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> engine/configdrive.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> engine/metadata.py#L18
> > https://github.com/openstack/mogan/blob/master/mogan/network/api.py#L18
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/aggregate.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/keypair.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/server_fault.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/server_group.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> scheduler/client/report.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> scheduler/filter_scheduler.py#L17
> >
> > 2. For the changes we follows what nova changed, should reference to the
> > original authors in the commit messages.
> >
> >
> > Please let me know if there are something else we need to do or there are
> > already some existing principles we can follow, thanks!
> >
> >
> >
> > [1] https://wiki.openstack.org/wiki/Mogan
> >
> >
> > --
> > Best Regards,
> > Zhenguo Niu
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing 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,
Zhenguo Niu
__
OpenStack Development Mailing 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] Your semi-monthly file injection and shelve mailer

[Matt Riedemann]

Just thought everyone might like to know about this.

I realized tonight that if you shelve an instance and it's offloaded, 
which is the default behavior, any injected files you had in the 
original instance are gone, and you can't specify them again on unshelve.


We're awesome.

The More You Know (tm)

--

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] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

On Thu, Sep 21, 2017 at 1:33 PM, Clint Byrum  wrote:

> Excerpts from Michael Still's message of 2017-09-20 10:25:17 -0600:
> > Dims, I'm not sure that's actually possible though. Many of these files
> > have been through rewrites and developed over a large number of years.
> > Listing all authors isn't practical.
> >
> > Given the horse has bolted on forking these files, I feel like a comment
> > acknowledging the original source file is probably sufficient.
> >
> > What is concerning to me is that some of these files are part of the
> "ABI"
> > of nova, and if mogan diverges from that then I think we're going to see
> > user complaints in the future. Specifically configdrive, and metadata
> seem
> > like examples of this. I don't want to see us end up in another "managed
> > cut and paste" like early oslo where nova continues to develop these and
> > mogan doesn't notice the changes.
> >
> > I'm not sure how we resolve that. One option would be to refactor these
> > files into a shared library.
> >
>
> Agreed 100%. It would be better to have something completely different
> than something that works 97% the same but constantly skews.
>
> Luckily, since these things are part of the ABI of Nova, they are
> versioned in many cases, and in all have a well defined interfaces on
> one side. Seems like it should be relatively straight forward to wrap
> the other side of them and call it a library.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Sounds great if we can call these ABI as a library, but seems still need
some refactoring on Nova side to make other projects be able to leverage it.

-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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][nova][mogan] How to show respect to the original authors?

[Davanum Srinivas]

Zhenguo,

I did some fancy surgery with both cinder and nova repos to add the
history, please check my repo here:
https://github.com/dims/mogan/commits/master

(Needed quota.py from cinder and rest of the files from Nova)

If that repo looks good, then we can request infra folks to replace
the current master with that one.

Thanks,
Dims

On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu  wrote:
>
>
> On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann  wrote:
>>
>> On 9/21/2017 11:55 AM, Mike Perez wrote:
>>>
>>> On 15:56 Sep 20, Flavio Percoco wrote:

 On 20/09/17 12:21 +, Jeremy Stanley wrote:
>
> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> [...]
>>
>> please indicate which file from Nova, so if anyone wanted to cross
>> check for fixes etc can go look in Nova
>
> [...]
>
> While the opportunity has probably passed in this case, the ideal
> method is to start with a Git fork of the original as your seed
> project (perhaps with history pruned to just the files you're
> reusing via git filter-branch or similar). This way the complete
> change history of the files in question is preserved for future
> inspection.


 If it's not too late, I would definitely recommend going with a fork,
 fwiw.

 Flavio

 --
 @flaper87
 Flavio Percoco
>>>
>>>
>>> +1 please fork instead.
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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'm pretty sure this ship has sailed. Mogan has been around since before
>> the PTG in Atlanta.
>>
>> --
>>
>> 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
>
>
> Yes, we are way past that, and there are already 1000+ commits since Mogan
> created,
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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][oslo.service] looping.RetryDecorator behavior

[Renat Akhmerov]

Thanks Josh,

I’m not sure I fully understand your point though. You mean it’s a legacy 
(deprecated?) code that we should never use in our code? Should it be 
considered a private class of oslo_service?

In our global requirements tenacity is configured as "tenacity>=3.2.1”, should 
we bump it to 4.4.0?

Renat Akhmerov
@Nokia

On 21 Sep 2017, 22:42 +0700, Joshua Harlow , wrote:
> It does look like is sort of a bug,
>
> Though in all honesty I wouldn't be using oslo.service or that looping
> code in the future for doing retrying...
>
> https://pypi.python.org/pypi/tenacity is a much better library with more
> `natural` syntax and works more as one would expect (even under threaded
> situations).
>
> If I could of I would of never let 'loopingcall.py' become a file that
> exists, but the past is the past, ha.
>
> Renat Akhmerov wrote:
> > Hi Oslo team,
> >
> > Can you please check the bug [1]?
> >
> > There may be a problem with how looping.RetryDecorator works. Just
> > stumbled on it in Mistral. Not sure if it’s really a bug or made by
> > design. If it’s by design then maybe we need to have more accurate
> > documentation for it.
> >
> > FYI: We use this decorator in Mistral and it’s also used in Nova, [2].
> >
> > [1] https://bugs.launchpad.net/oslo.service/+bug/1718635
> > [2]
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py
> >
> > Thanks
> >
> > Renat Akhmerov
> > @Nokia
> >
> > __
> > OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Matt Riedemann]

I just wanted to highlight to people that there seems to be a series of 
garbage patches in various projects [1] which are basically doing things 
like fixing a single typo in a code comment, or very narrowly changing 
http to https in links within docs.


Also +1ing ones own changes.

I've been trying to snuff these out in nova, but I see it's basically a 
pattern widespread across several projects.


This is the boilerplate comment I give with my -1, feel free to employ 
it yourself.


"Sorry but this isn't really a useful change. Fixing typos in code 
comments when the context is still clear doesn't really help us, and 
mostly seems like looking for padding stats on stackalytics. It's also a 
drain on our CI environment.


If you fixed all of the typos in a single module, or in user-facing 
documentation, or error messages, or something in the logs, or something 
that actually doesn't make sense in code comments, then maybe, but this 
isn't one of those things."


I'm not trying to be a jerk here, but this is annoying to the point I 
felt the need to say something publicly.


[1] https://review.openstack.org/#/q/author:%255E.*inspur.*

--

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] Garbage patches for simple typo fixes

[Zhipeng Huang]

Let's not forget the epic fail earlier on the "contribution.rst fix" that
almost melt down the community CI system.

For any companies that are doing what Matt mentioned, please be aware that
the dev community of the country you belong to is getting hurt by your
stupid activity.

Stop patch trolling and doing something meaningful.

On Fri, Sep 22, 2017 at 10:21 AM, Matt Riedemann 
wrote:

> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
>
> Also +1ing ones own changes.
>
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
>
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
>
> "Sorry but this isn't really a useful change. Fixing typos in code
> comments when the context is still clear doesn't really help us, and mostly
> seems like looking for padding stats on stackalytics. It's also a drain on
> our CI environment.
>
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
>
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
>
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
>
> --
>
> 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
>



-- 
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] [all][api] POST /api-sig/news

[Joe Topjian]

> Microversions also reared their head in the form of a long discussion
> about how SDK developers and users are consuming microversions at a very
> granular level. This discussion opened many surprised eyes as we learned
> how different SDK platforms deal with microversions, and what exactly are
> the best practices. We agreed that it is generally good for an SDK to
> shield its users from the details of microversions, but to allow power
> users to access them if they care to.
>

I wanted to add some notes about this.

I wasn't able to attend the PTG but I was delighted that somehow this topic
came up - and it looks like it was a very in-depth conversation, too. The
etherpad notes look to have accurately summarized the difficulty we're
having with microversions in Gophercloud.

Difficult as the problem is, we're not exactly stuck... yet, anyway. As one
of the maintainers of Gophercloud, one thing I wanted to mention is that
there shouldn't be a concern of communication problems or anything of the
sort (ie: why haven't these Gophercloud guys reached out??). While the
discussion of microversions has been going on for almost two months, we
only have, at best, a couple of hours a week to research solutions. If
either we reach a solution or unfortunately come up short, I plan to post
to the api-consumer list with a story of the experience, feedback, and/or a
call for help that we're flat out stuck. At the moment, anything more would
be commentating the sport of virtual whiteboarding :)

On the topic of microversions itself, I'm finding this to be a fun
challenge. I like the core goals of microversions, and given that there
isn't precedence for this type of thing (unless I'm mistaken) makes it more
fun. I do hope that we can implement a solution that enables users of
Gophercloud to easily leverage microversions and do some really cool stuff.
__
OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Renat Akhmerov]

+1000

Thanks for bringing this up, I fully agree that we need to do something about 
it.

Some time ago I even had an idea of creating a case when we intentionally 
exclude a person from a team for constantly doing things like this and ignoring 
our comments. Although I understand it slightly conflicts with our openness 
principle.. It’s just really tempting quite often.

Renat Akhmerov
@Nokia

On 22 Sep 2017, 09:26 +0700, Zhipeng Huang , wrote:
> Let's not forget the epic fail earlier on the "contribution.rst fix" that 
> almost melt down the community CI system.
>
> For any companies that are doing what Matt mentioned, please be aware that 
> the dev community of the country you belong to is getting hurt by your stupid 
> activity.
>
> Stop patch trolling and doing something meaningful.
>
> > On Fri, Sep 22, 2017 at 10:21 AM, Matt Riedemann  
> > wrote:
> > > I just wanted to highlight to people that there seems to be a series of 
> > > garbage patches in various projects [1] which are basically doing things 
> > > like fixing a single typo in a code comment, or very narrowly changing 
> > > http to https in links within docs.
> > >
> > > Also +1ing ones own changes.
> > >
> > > I've been trying to snuff these out in nova, but I see it's basically a 
> > > pattern widespread across several projects.
> > >
> > > This is the boilerplate comment I give with my -1, feel free to employ it 
> > > yourself.
> > >
> > > "Sorry but this isn't really a useful change. Fixing typos in code 
> > > comments when the context is still clear doesn't really help us, and 
> > > mostly seems like looking for padding stats on stackalytics. It's also a 
> > > drain on our CI environment.
> > >
> > > If you fixed all of the typos in a single module, or in user-facing 
> > > documentation, or error messages, or something in the logs, or something 
> > > that actually doesn't make sense in code comments, then maybe, but this 
> > > isn't one of those things."
> > >
> > > I'm not trying to be a jerk here, but this is annoying to the point I 
> > > felt the need to say something publicly.
> > >
> > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > >
> > > --
> > >
> > > 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
>
>
>
> --
> 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
__
OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[David Moreau Simard]

Wow, Matt, that's excellent timing.
Day for day, an exact year after the last thread of this kind [1].

Thanks for speaking up, I didn't want to it'd seem like encouraging a
stereotype or prejudice towards certain kind of contributions (or
contributors) but I've also been rolling my eyes a lot recently.
It does look like those users are just seeking to pad statistics, but
this isn't the first time this kind of topic comes up.

Some other contributors with similar patterns:

- https://review.openstack.org/#/q/author:%255E.*unionpay.*
- https://review.openstack.org/#/q/author:%255E.*fiberhome.*
- https://review.openstack.org/#/q/author:%255E.*sina.*

There are some thoughts in the thread from last year but I don't think
any concrete measures were put in place to encourage better and more
meaningful contributions.

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104173.html


David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Thu, Sep 21, 2017 at 10:21 PM, Matt Riedemann  wrote:
> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
>
> Also +1ing ones own changes.
>
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
>
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
>
> "Sorry but this isn't really a useful change. Fixing typos in code comments
> when the context is still clear doesn't really help us, and mostly seems
> like looking for padding stats on stackalytics. It's also a drain on our CI
> environment.
>
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
>
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
>
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
>
> --
>
> 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 Development Mailing 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] Garbage patches for simple typo fixes

[Jeremy Freudberg]

Thanks for being brave enough to say it publicly. Not sure how many
more times I can stomach reading such classic patches as "Optimize the
link address" or "Replace six.iteritems() with .items()".

Yes, it is still possible for us to be an open community while also
minimizing the amount of useless patches.

Messages like the sample Matt provided are part of the solution.
Resisting the urge to -2/force-abandon without explanation is part of
the solution, too. But they aren't the whole solution.

The TC's emerging Top 5 help-wanted list is a step in the right
direction towards solving this problem. Let's publicize the crap out
of that. And we can go further, with project-specific help wanted
lists. And how about a better way to identify and promote issues which
are both low-hanging fruit AND important (they aren't actually that
rare!).

Turning towards more radical solutions: 1) Bake something into
git-review which will print out some agreed-up community guidelines
for what constitutes a useful patch, as well as any
repository-specific guidelines. To keep it reasonable, only show the
message the first time a contributor submits to that repository. 2)
Register fingerprints of common unhelpful patches and have a bot
similar to Elastic Recheck automatically review and comment. 3) Delay
spin-up of resource-intensive/long-running CI jobs until after some
initial review has been added or time has passed. Authorized
contributors, not necessarily synonymous with cores, can override the
delay if there's a critical patch which needs to get through the queue
quickly.

Those are just some ideas off the top of my head, so feel free to tear me apart.

Looking forward to seeing where this conversation goes this time around.



On Thu, Sep 21, 2017 at 10:21 PM, Matt Riedemann  wrote:
> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
>
> Also +1ing ones own changes.
>
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
>
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
>
> "Sorry but this isn't really a useful change. Fixing typos in code comments
> when the context is still clear doesn't really help us, and mostly seems
> like looking for padding stats on stackalytics. It's also a drain on our CI
> environment.
>
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
>
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
>
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
>
> --
>
> 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 Development Mailing 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] Garbage patches for simple typo fixes

[Chris Smart]

On Fri, 22 Sep 2017, at 12:21, Matt Riedemann wrote:
> I just wanted to highlight to people that there seems to be a series of 
> garbage patches in various projects [1] which are basically doing things 
> like fixing a single typo in a code comment, or very narrowly changing 
> http to https in links within docs.
> 
> Also +1ing ones own changes.
> 
> I've been trying to snuff these out in nova, but I see it's basically a 
> pattern widespread across several projects.
> 

For what it's worth, I agree. A few days ago I gave a -1 and commented
on around 50 patches which were adding --- to the top of generally two
yaml files: one was a template the other was a test.

Another patchset removed a single space from the end of a line of a
comment.

After my comments they ware all abandoned.

Given the waste of resources, I can't help but wonder if we should be
re-visiting the way initial check gate is kicked off?

Should someone else have to do an initial +1? (Acknowledging that this
could be a colleague and other offender.)

Or could the gate be smarter about the types of changes (like checking
for one liners or changes to comments, etc)?

Or at least there should be a way for anyone to kill a review if it is
clearly a waste of resources?

Or detect patch bombing across projects.

Sadly people are going to abuse this, although probably generally out of
ignorance. However, how can we be a) smarter about the gate, and b) have
a big stick handy.

Perhaps when developers sign up to the CLA, this issue should be in big
bold writing and we can use that as a stick to disable people's access
to Gerrit? That should be a pretty big incentive to behave, it's hard to
do your job when your access has been removed (and only reinstated after
a specified process).

Anyway just some thoughts.

Cheers,
-c

__
OpenStack Development Mailing 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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

Thanks dims, that's cool :D

I'll make sure there's no new patches landed to master before replacing the
repo.

On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas  wrote:

> Zhenguo,
>
> I did some fancy surgery with both cinder and nova repos to add the
> history, please check my repo here:
> https://github.com/dims/mogan/commits/master
>
> (Needed quota.py from cinder and rest of the files from Nova)
>
> If that repo looks good, then we can request infra folks to replace
> the current master with that one.
>
> Thanks,
> Dims
>
> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu 
> wrote:
> >
> >
> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann 
> wrote:
> >>
> >> On 9/21/2017 11:55 AM, Mike Perez wrote:
> >>>
> >>> On 15:56 Sep 20, Flavio Percoco wrote:
> 
>  On 20/09/17 12:21 +, Jeremy Stanley wrote:
> >
> > On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> > [...]
> >>
> >> please indicate which file from Nova, so if anyone wanted to cross
> >> check for fixes etc can go look in Nova
> >
> > [...]
> >
> > While the opportunity has probably passed in this case, the ideal
> > method is to start with a Git fork of the original as your seed
> > project (perhaps with history pruned to just the files you're
> > reusing via git filter-branch or similar). This way the complete
> > change history of the files in question is preserved for future
> > inspection.
> 
> 
>  If it's not too late, I would definitely recommend going with a fork,
>  fwiw.
> 
>  Flavio
> 
>  --
>  @flaper87
>  Flavio Percoco
> >>>
> >>>
> >>> +1 please fork instead.
> >>>
> >>>
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing 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'm pretty sure this ship has sailed. Mogan has been around since before
> >> the PTG in Atlanta.
> >>
> >> --
> >>
> >> 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
> >
> >
> > Yes, we are way past that, and there are already 1000+ commits since
> Mogan
> > created,
> >
> > --
> > Best Regards,
> > Zhenguo Niu
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing 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,
Zhenguo Niu
__
OpenStack Development Mailing 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] [self-healing] When shall have self-healing meeting?

[Lajos Katona]

Hi,

In Denver there was a session on self-healing and how to give direction 
to the ambitions around the topic, and some agreement that bi-weekly 
meeting should be organized.
Is there anybody who knows some details about that? Doddle, irc channel 
etc?


Thanks in advance for the answer.
Regards
Lajos

__
OpenStack Development Mailing 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] [vitrage] Extending Topology

[Muhammad Usman]

Thanks Ifat,

For guiding me to how to start with contribution on implementation side.

Meanwhile, I am looking at blueprints and bugs before attending next
meeting.

-- 

*Regards*

*Muhammad Usman*
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com
+92 (323) 5599 068

On Fri, Sep 22, 2017 at 5:22 AM, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi Usman,
>
>
>
> Great to hear back from you J
>
>
>
> You are more than welcome to join our efforts. You can look at the list of
> blueprints[1], suggest new ones, implement existing, or solve bugs[2].
> Whatever you chose, we will be happy to assist.
>
>
>
> The ways to contact Vitrage developers are here in the mailing list, or on
> #openstack-vitrage IRC channel. In addition, we meet every Wednesday at
> 8:00 UTC on #openstack-meeting-4, so you can join and discuss whatever
> topic you are interested in.
>
>
>
> [1] https://blueprints.launchpad.net/vitrage
>
> [2] https://bugs.launchpad.net/vitrage
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
> *From: *Muhammad Usman 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Thursday, 21 September 2017 at 4:59
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [vitrage] Extending Topology
>
>
>
> Dear Ifat,
>
>
>
> Usman is here. Previously, I contacted you for contributing to OpenStack
> Vitrage project but could not  follow up with you for sometime due to
> various reasons.
>
>
>
> However, to get actively involved in OpenStack project, I have decided to
> join OpenStack Summit in Sydney.
>
>
>
> Also, based on my previous experience withe Vitrage project that is
> already in shape, so its not easy to propose new ideas.
>
>
>
> Therefore, a better way to start contributing to development side with
> already proposed and on-going development.
>
>
> --
>
>
> * Regards*
>
>
> *Muhammad Usman*
> Application Engineer
> LMK Resources (pvt) Limited
> www.lmkr.com
> +92 (323) 5599 068
>
>
>
>
>
> __
> OpenStack Development Mailing 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