Re: [openstack-dev] [all] pypy broken for many repos

2017-09-23 Thread Andreas Jaeger 

On 09/17/2017 08:32 AM, Andreas Jaeger wrote:

Currently we use pypy for a couple of projects and many of these fail
with the version of pypy that we use.

A common error is  "Pypy fails with "RuntimeError: cryptography 1.9 is
not compatible with PyPy < 5.3. Please upgrade PyPy to use this library.".

Example:
http://logs.openstack.org/51/503951/1/check/gate-python-neutronclient-pypy/206ac6a/

I propose in https://review.openstack.org/#/c/504748/ to remove pypy
from those repos where it fails.

Alternative would be investigating what is broken and fix it. Anybody
interested to do this?

Or should we remove the pypy jobs where they fail. I pushed
https://review.openstack.org/504748 up and marked it as WIP, will wait
for a week to see outcome of this discussion,


I've removed the WIP now...

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] [octavia][neutron-fwaas][tap-as-a-service][networking-sfc][networking-bgpvpn][neutron-lbaas][blazar][qa] Shrink Tempest scenario manager copy on tempest plugin

2017-09-23 Thread Ghanshyam Mann 
Hi Teams,

In Pike release QA team has copied the Tempest scenario manager on
plugin side to refactor the same and to avoid breaking any plugin [1].
But in many plugins, scenario manager was copied as complete and
expected to shrink by each plugin as per their usage.

Because scenario manager has lot of class/methods which might not be
used by each plugin. Those class/method internally use many tempest
interfaces which all might not be stable. Tempest is trying to make
them stable interfaces for plugin. That is ongoing work from QA team
since many releases. This work sometime break the scenario manager
copy on plugin side. One ongoing example is to make object storage
service clients as stable interfaces [2].

To avoid such issues i have started to shrink the scenario manager
copy on remaining plugin side [3]. Each corresponding team is
requested to merge them. Also those are needed to backport on stable
branches as plugins are still in project repo. I have backported some
of them for Pike [4] and project team can backport to other stable
branches based on their need.

Please ping us on QA channel for any clarification.

..1 http://lists.openstack.org/pipermail/openstack-dev/2017-February/112938.html
..2 
https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/consistent-service-method-names
..3 
https://review.openstack.org/#/q/topic:shrink-scenario-manager+(status:open+OR+status:merged)
..4 
https://review.openstack.org/#/q/topic:shrink-scenario-manager-stable/pike+(status:open+OR+status:merged)

-gmann

__
OpenStack Development Mailing 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][heat] Heat meeting time changed to 13:00 Wed. at #heat

2017-09-23 Thread Rico Lin 
Hi all

After discussion.
Heat decided to move our meeting to Wed. 13::00 UTC at #heat
Which is two hours earlier than the previous one.
So our meeting start from this week will be host at 13:00 UTC in #heat
(weekly).
We will keep doing 13:00 and see if that works for all.
Feel free to join us and provide your ideas and works with us:
https://wiki.openstack.org/wiki/Meetings/HeatAgenda

Already propose irc meeting change: https://review.openstack.org/506901


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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

2017-09-23 Thread Doug Hellmann 
Excerpts from Qiming Teng's message of 2017-09-23 23:55:34 +0800:
> To some extent, I think Zhipeng is right. There are times we as a
> community have to do something beyond mentoring new developers. One of
> the reasons behind these patches are from the management chain of those
> companies. They need numbers, and they don't care what kind of
> contributions were made. They don't bother read these emails.
> 
> Another fact is that some companies are doing such things not just in the
> OpenStack community. Their developers are producing tons of low-quality
> "patches" to play this as a game in other communities as well. If we
> don't place a STOP sign, things will never get improved. By not doing
> something, we are hurting everyone, including those developers who could
> have done more meaningful contributions, though their number of patches
> may decrease.
> 
> Just my 2 cents.
> 
> - Qiming 

This may be true. Before we create harsh processes, however, we
need to collect the data to show that other attempts to provide
guidance have not worked.  We have a lot of anecdotal information
right now. We need to collect that and summarize it. If the results
show that there are clear abuses, rather than misunderstandings,
then we can use the data to design effective blocks without hurting
other contributors or creating a reputation that our community is
not welcoming.

Doug

> 
> On Sat, Sep 23, 2017 at 08:34:18AM +0800, Zhipeng Huang wrote:
> > Hi Paul,
> > 
> > Unfortunately I know better on this matter and it is not the matter of
> > topic dispute as many people on this thread who has been disturbed and
> > annoyed by the padding/trolling.
> > 
> > So yes I'm sticking with stupid because it hurts the OpenStack community as
> > a whole and hurts the reputation of the dev community from my country which
> > in large are great people with good hearts and skills.
> > 
> > I'm not giving even an inch of the benefit of doubt to these padding
> > activities and people behind it.
> > 
> > 
> > On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
> > wrote:
> > 
> 

__
OpenStack Development Mailing 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

2017-09-23 Thread Qiming Teng 
On Fri, Sep 22, 2017 at 04:47:27PM -0700, Michael Johnson wrote:
> A recent extreme example:
> https://review.openstack.org/#/c/494981/1/specs/version0.8/active_passive_loadbalancer.rst

Haha, buddy, let me fix your name! ;)

> I would love to have a boilerplate statement I can use as a template
> for things like this.  I feel bad -1/-2 these as I want to encourage
> involvement, but they are a drain on the system.
> 
> Michael
> 
> 
> On Fri, Sep 22, 2017 at 4:18 PM, Zhipeng Huang  wrote:
> > Hi Doug,
> >
> > Absolutely glad to help on this matter. We could take this offline first via
> > email or irc chat and then comes up with a solution for the broader
> > community to review
> >


__
OpenStack Development Mailing 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

2017-09-23 Thread Qiming Teng 
To some extent, I think Zhipeng is right. There are times we as a
community have to do something beyond mentoring new developers. One of
the reasons behind these patches are from the management chain of those
companies. They need numbers, and they don't care what kind of
contributions were made. They don't bother read these emails.

Another fact is that some companies are doing such things not just in the
OpenStack community. Their developers are producing tons of low-quality
"patches" to play this as a game in other communities as well. If we
don't place a STOP sign, things will never get improved. By not doing
something, we are hurting everyone, including those developers who could
have done more meaningful contributions, though their number of patches
may decrease.

Just my 2 cents.

- Qiming 

On Sat, Sep 23, 2017 at 08:34:18AM +0800, Zhipeng Huang wrote:
> Hi Paul,
> 
> Unfortunately I know better on this matter and it is not the matter of
> topic dispute as many people on this thread who has been disturbed and
> annoyed by the padding/trolling.
> 
> So yes I'm sticking with stupid because it hurts the OpenStack community as
> a whole and hurts the reputation of the dev community from my country which
> in large are great people with good hearts and skills.
> 
> I'm not giving even an inch of the benefit of doubt to these padding
> activities and people behind it.
> 
> 
> On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
> wrote:
> 


__
OpenStack Development Mailing 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

2017-09-23 Thread Ildiko Vancsa 

> On 2017. Sep 23., at 9:11, Doug Hellmann  wrote:
> 
> Excerpts from Huang Zhiteng's message of 2017-09-23 10:00:00 +0800:
>> On Sat, Sep 23, 2017 at 8:34 AM, Zhipeng Huang  wrote:
>>> Hi Paul,
>>> 
>>> Unfortunately I know better on this matter and it is not the matter of topic
>>> dispute as many people on this thread who has been disturbed and annoyed by
>>> the padding/trolling.
>>> 
>>> So yes I'm sticking with stupid because it hurts the OpenStack community as
>>> a whole and hurts the reputation of the dev community from my country which
>>> in large are great people with good hearts and skills.
>>> 
>>> I'm not giving even an inch of the benefit of doubt to these padding
>>> activities and people behind it.
>> Hi Zhipeng,
>> 
>> Not sure how much you have been involved in the dev community in
>> China, but it's now a good time to talk to those companies (in public
>> or private) and ask them to stop encourage their developers to submit
>> such changes.
> 
> I would prefer to set up a system where we can have those sorts of
> conversations in private, to encourage people to contribute
> constructively instead of shaming them.
> 
> Doug

+1, I completely agree.

In my earlier experience with this the main reason for this behavior to happen 
is the lack of experience with the tools and the open source environment and 
ways of working. As we are working with people all around the globe we also 
need to take into consideration the different cultures and how they communicate 
and handle situations like this.

We should put emphasis on remaining an open, friendly and diverse community by 
providing education and help to those people who need it the best way we can. 
And this should include not assuming the worse before we actually know why 
things happened and not publicly shaming people, but to provide mentorship.

I think this is extremely important, and I’m happy to be a ‘go to person’ and 
help people understand how these systems work and what is the best way to join 
an open source community like OpenStack in case you need more people to get 
involved in communicating our principles.

Thanks,
Ildikó
IRC: ildikov


> 
>> 
>>> 
>>> 
>>> On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
>>> wrote:
 
 On Fri, Sep 22, 2017 at 10:26:09AM +0800, 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.
> 
 Sorry, but I found this comment over the line. Just because you disagree
 with
 the $topic at hand, doesn't mean you should default to calling it
 'stupid'. Give
 somebody the benefit of not knowing any better.
 
 This is not a good example of encouraging anybody to contribute to the
 project.
 
 -Paul
 
> 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
>>

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-23 Thread Doug Hellmann 
Excerpts from Huang Zhiteng's message of 2017-09-23 10:00:00 +0800:
> On Sat, Sep 23, 2017 at 8:34 AM, Zhipeng Huang  wrote:
> > Hi Paul,
> >
> > Unfortunately I know better on this matter and it is not the matter of topic
> > dispute as many people on this thread who has been disturbed and annoyed by
> > the padding/trolling.
> >
> > So yes I'm sticking with stupid because it hurts the OpenStack community as
> > a whole and hurts the reputation of the dev community from my country which
> > in large are great people with good hearts and skills.
> >
> > I'm not giving even an inch of the benefit of doubt to these padding
> > activities and people behind it.
> Hi Zhipeng,
> 
> Not sure how much you have been involved in the dev community in
> China, but it's now a good time to talk to those companies (in public
> or private) and ask them to stop encourage their developers to submit
> such changes.

I would prefer to set up a system where we can have those sorts of
conversations in private, to encourage people to contribute
constructively instead of shaming them.

Doug

> 
> >
> >
> > On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
> > wrote:
> >>
> >> On Fri, Sep 22, 2017 at 10:26:09AM +0800, 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.
> >> >
> >> Sorry, but I found this comment over the line. Just because you disagree
> >> with
> >> the $topic at hand, doesn't mean you should default to calling it
> >> 'stupid'. Give
> >> somebody the benefit of not knowing any better.
> >>
> >> This is not a good example of encouraging anybody to contribute to the
> >> project.
> >>
> >> -Paul
> >>
> >> > 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

[openstack-dev] [nova] reset key pair during rebuilding

2017-09-23 Thread LIU Yulong 
Hi nova developers,

This mail is proposed to reconsider the key pair resetting of instance. The
nova queens PTG discuss is here: https://etherpad.openstack.org/p/nova-ptg-
queens L498. And there are now two proposals.

1. SPEC 1:  https://review.openstack.org/#/c/375221/ started by me
(liuyulong) since sep 2016.

   This spec will allow setting the new key_name for the instance during
rebuild API. That’s a very simple and well-understood approach:

   - Make consistent with rebuild API properties, such as name, imageRef,
   metadata, adminPass etc.
   - Rebuild API is something like `recreating`, this is the right way to
   do key pair updating. For keypair-login-only VM, this is the key point.
   - This does not involve to other APIs like reboot/unshelve etc.
   - Easy to use, only one API.

By the way, here is the patch (https://review.openstack.org/#/c/379128/)
which has implemented this spec. And it stays there more than one year too.

2. SPEC 2 : https://review.openstack.org/#/c/506552/ propose by Kevin_zheng.

This spec supposed to add a new updating API for one instance’s key pair.
This one has one foreseeable advantage for this is to do instance running
key injection.

But it may cause some issues:

   - This approach needs to update the instance key pair first (one step,
   API call). And then do a reboot/rebuild or any actions causing the vm
   restart (second step, another API call). Firstly, this is waste, it use two
   API calls. Secondly, if updating key pair was done, and the reboot was not.
   That may result an inconsistent between instance DB key pair and guest VM
   inside key. Cloud user may confused to choose which key should be used to
   login.
   - For the second step (reboot), there is a strong constraint is that
   cloud-init config needs to be set to running-per-booting. But if a cloud
   platform all images are set cloud-init to per-deployment. In order to
   achieve this new API goal, the entire cloud platform images need updating.
   This will cause a huge upgrading work for entire cloud platform images.
   They need to change all the images cloud-init config from
   running-per-deployment to running-every-boot. But that still can not solve
   the inconsistent between DB keypair and guest-key. For instance, if the
   running VM is based on a running-once-cloud-init image: 1. create image
   from this VM; 2. change the keypair of the new VM; 3. reboot still can not
   work because of the old config of per-deployment-running.
   - For another second step (rebuild), if they have to rebuild, or rebuild
   is the only one way to deployment new key, we are going back to rebuild
   SPEC 1. Two steps for keypair updating are not good. Why don’t directly
   using SPEC 1?
   - Another perspective to think about this is that SPEC 2 is expanding
   the functionality of reboot. What about one day user want to change
   password/name/personality at a reboot?
   - Cloud user may still have questions: why key pair can not be updated
   during rebuilding ? Why name/image/personality can?
   - If new API does not supporting running injection, the DB keypair and
   guest keypair are inconsistent if cloud user forget a rebuiding, reboot,
   unshelving API call.


In conclusion, IMHO SPEC 1 is the reasonable way to set key pair for
rebuild API. It’s simple and easy.

SPEC 2 can be used for future running key injection. And it is still a way
for reboot  API to deploy the new key. But the its disadvantages are as
stated above.


There already has some discuss [1] about this with Matt and Kevin.

Sincerely hope to receive your opinion. Feel free to ping me at IRC
openstack-nova, my nick is liuyulong. Thank you very much.



[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/
%23openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07
__
OpenStack Development Mailing 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] reset key pair during rebuilding

2017-09-23 Thread LIU Yulong 
Hi nova developers,

This mail is proposed to reconsider the key pair resetting of instance. The
nova queens PTG discuss is here:
https://etherpad.openstack.org/p/nova-ptg-queens L498. And there are now
two proposals.

1. SPEC 1:  https://review.openstack.org/#/c/375221/ started by me
(liuyulong) since sep 2016.

   This spec will allow setting the new key_name for the instance during
rebuild API. That’s a very simple and well-understood approach:

   - Make consistent with rebuild API properties, such as name, imageRef,
   metadata, adminPass etc.
   - Rebuild API is something like `recreating`, this is the right way to
   do key pair updating. For keypair-login-only VM, this is the key point.
   - This does not involve to other APIs like reboot/unshelve etc.
   - Easy to use, only one API.

By the way, here is the patch (https://review.openstack.org/#/c/379128/)
which has implemented this spec. And it stays there more than one year too.

2. SPEC 2 : https://review.openstack.org/#/c/506552/ propose by Kevin_zheng.

This spec supposed to add a new updating API for one instance’s key pair.
This one has one foreseeable advantage for this is to do instance running
key injection.

But it may cause some issues:

   - This approach needs to update the instance key pair first (one step,
   API call). And then do a reboot/rebuild or any actions causing the vm
   restart (second step, another API call). Firstly, this is waste, it use two
   API calls. Secondly, if updating key pair was done, and the reboot was not.
   That may result an inconsistent between instance DB key pair and guest VM
   inside key. Cloud user may confused to choose which key should be used to
   login.
   - For the second step (reboot), there is a strong constraint is that
   cloud-init config needs to be set to running-per-booting. But if a cloud
   platform all images are set cloud-init to per-deployment. In order to
   achieve this new API goal, the entire cloud platform images need updating.
   This will cause a huge upgrading work for entire cloud platform images.
   They need to change all the images cloud-init config from
   running-per-deployment to running-every-boot. But that still can not solve
   the inconsistent between DB keypair and guest-key. For instance, if the
   running VM is based on a running-once-cloud-init image: 1. create image
   from this VM; 2. change the keypair of the new VM; 3. reboot still can not
   work because of the old config of per-deployment-running.
   - For another second step (rebuild), if they have to rebuild, or rebuild
   is the only one way to deployment new key, we are going back to rebuild
   SPEC 1. Two steps for keypair updating are not good. Why don’t directly
   using SPEC 1?
   - Another perspective to think about this is that SPEC 2 is expanding
   the functionality of reboot. What about one day user want to change
   password/name/personality at a reboot?
   - Cloud user may still have questions: why key pair can not be updated
   during rebuilding ? Why name/image/personality can?
   - If new API does not supporting running injection, the DB keypair and
   guest keypair are inconsistent if cloud user forget a rebuiding, reboot,
   unshelving API call.


In conclusion, IMHO SPEC 1 is the reasonable way to set key pair for
rebuild API. It’s simple and easy.

SPEC 2 can be used for future running key injection. And it is still a way
for reboot  API to deploy the new key. But the its disadvantages are as
stated above.


There already has some discuss [1] about this with Matt and Kevin.

Sincerely hope to receive your opinion. Feel free to ping me at IRC
openstack-nova, my nick is liuyulong. Thank you very much.



[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-22.log.html#t2017-09-22T14:05:07
__
OpenStack Development Mailing 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] [octavia][sqlalchemy] Specify 'extend_existing=True' to redefine options and columns on an existing Table object.

2017-09-23 Thread Pradeep Singh 
Hello All,

I added two tables schema in patch https://review.openstack.org/#/c/486499/,
and when i run unit tests i am getting error which says,
InvalidRequestError: Table 'provisioning_status' is already defined for
this MetaData instance. Specify 'extend_existing=True' to redefine options
and columns on an existing Table object.

Log location:
http://logs.openstack.org/99/486499/3/check/gate-octavia-python27-ubuntu-xenial/a7924bc/console.html

Can any body help me.

Thanks,
Pradeep Singh
__
OpenStack Development Mailing 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

2017-09-23 Thread Adam Lawson 
Quick note (started quick anyway) since I haven't been as active on this
list as I have in the past.

Two things:

   1. Great topic and addresses a historical, persistent well-known problem
   with OpenStack - complexity. Technology is useless if it's so complex new
   organizations can't get it to work easily or reliably.

   2. I'm gonna call it as I'm seeing it: it makes me sick to read
   statements/replies by some members taking the time to itemize every single
   suggestion by another member to simplify OpenStack with one snarky remark
   after another. Thankfully (hopefully?) the influence of those individuals
   will lessen over time. It's literally poisonous to read and holds no value.

Okay aside from that, as an OpenStack architect now increasing my focus on
AWS/GCP as well as OpenStack, I would suggest there are two key areas with
OpenStack that desperately need to be simplified: the architecture and the
implementation. I never hear people say the architecture is too complex so
while that can see some improvements, what I hear over and over and over
again is how hard it is to deploy OpenStack on more than one machine
quickly and easily. I think that has to be the priority. Until deployments
are easy and stable and 'just work', that's a missed opportunity and
OpenStack will continue to scare away potential new users -- like we need
any more of that. OpenStack is deep in the trough of disillusionment (my
perception) whether others recognize it or not so anything that makes
OpenStack adoption easier should be our Numero Uno goal.

Lastly, I do think GUI's make deployments easier and because of that, I
feel they're critical. There is more than one vendor whose built and
distributes a free GUI to ease OpenStack deployment and management. That's
a good start but those are the opinions of a specific vendor - not he OS
community. I have always been a big believer in a default cloud
configuration to ease the shock of having so many options for everything. I
have a feeling however our commercial community will struggle with
accepting any method/project other than their own as being part a default
config. That will be a tough one to crack.

That's what I got tonight. hve a great weekend.

//adam


*Adam Lawson*

Principal Architect
Office: +1-916-794-5706

On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum  wrote:

> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev