Re: [openstack-dev] [Glance] Nitpicking in code reviews

[John Bresnahan]

FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy 
enough thing to get right and speaks to the quality standard to which 
the product is held even in commit messages and comments (consider the 
'broken window theory').  Of course everyone makes mistakes (I am a 
terrible speller) but correcting a spelling error should be a trivial 
matter.  If a reviewer notices a spelling error I would expect them to 
point it.


On 3/11/15 2:22 PM, Kuvaja, Erno wrote:

Hi all,

Following the code reviews lately I’ve noticed that we (the fan club
seems to be growing on weekly basis) have been growing culture of
nitpicking [1] and bikeshedding [2][3] over almost every single change.

Seriously my dear friends, following things are not worth of “-1” vote
if even a comment:

1)Minor spelling errors on commit messages (as long as the message comes
through and flags are not misspelled).

2)Minor spelling errors on comments (docstrings and documentation is
there and there, but comments, come-on).

3)Used syntax that is functional, readable and does not break
consistency but does not please your poem bowel.

4)Other things you “just did not realize to check if they were there”.
After you have gone through the whole change go and look your comments
again and think twice if your concern/question/whatsoever was addressed
somewhere else than where your first intuition would have dropped it.

We have relatively high volume for glance at the moment and this
nitpicking and bikeshedding does not help anyone. At best it just
tightens nerves and breaks our group. Obviously if there is “you had ONE
job” kind of situations or there is relatively high amount of errors
combined with something serious it’s reasonable to ask fix the typos on
the way as well. The reason being need to increase your statistics,
personal perfectionist nature or actually I do not care what; just stop
or go and do it somewhere else.

Love and pink ponies,

-Erno

[1] www.urbandictionary.com/define.php?term=nitpicking


[2] http://bikeshed.com

[3] http://en.wiktionary.org/wiki/bikeshedding



__
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] [Glance] Core nominations.

[John Bresnahan]

On 3/4/15 11:31 PM, Thierry Carrez wrote:

Flavio Percoco wrote:

[...]
I personally don't think adding new cores without cleaning up that
list is something healthy for our community, which is what we're
trying to improve here. Therefore I'm still -2-W on adding new folks
without removing non-active core members.


It's also *extremely* easy to add back long-inactive members if they
happen to come back.

Again, core is not a badge, it corresponds to a set of duties. If some
people don't fill those duties anymore, it's better to remove them than
to keep them around: it maintains the standards of expected review
activity fore core reviewers at a high level.


While I long to have more time to properly contribute to glance and I 
miss the time when I did, as an inactive core member I also agree that 
rotation makes sense.


__
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][docker] docker and openstack disagree about the IP address

[John Bresnahan]

Hello all,

I am trying to setup a devstack vagrant virtualbox VM and running into 
network troubles.  I can successful launch an container but docker and 
openstack disagree on the IP address of that instance. Docker has the 
correct IP.  I an running devstack stable/havana on ubuntu 12.04.  My 
session is below.  Any help is greatly appreciated.


Thanks,

John

nova boot --flavor 1 --image 5709b62d-0b54-43d9-82b6-fd149e477350 tst

nova list
+--+--+++-+--+
| ID   | Name | Status | Task State | 
Power State | Networks |

+--+--+++-+--+
| 4f331975-497d-4cbe-ad73-ca333e178e19 | tst  | ACTIVE | - | NOSTATE 
| private=10.0.0.2 |

+--+--+++-+--+

$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
^C
--- 10.0.0.2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms
pipe 3

$ docker ps
CONTAINER IDIMAGE COMMANDCREATED 
STATUS PORTSNAMES
ebc7eae3e777172.16.129.20:5042/docker-busybox:latest 
sh 9 minutes ago   Up 9 
minutes lonely_pasteur
a4ea16899219docker-registry:latest ./docker-registry/ru   24 
minutes ago  Up 24 minutes 0.0.0.0:5042->5000/tcp   tender_brown


$ docker inspect ebc7eae3e777

"NetworkSettings": {
"IPAddress": "172.17.0.3",
...

$ ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_req=1 ttl=64 time=0.081 ms
64 bytes from 172.17.0.3: icmp_req=2 ttl=64 time=0.053 ms






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

Re: [openstack-dev] Glance Tasks

[John Bresnahan]

George,

Thanks for the comments, they make a lot of sense.  There is a Glance 
team meeting on Thursday where we would like to push a bit further on 
this.  Would you mind sending in a few more details? Perhaps a sample of 
what your ideal layout would be?  As an example, how would you prefer 
actions are handled that do not effect a currently existing resource but 
ultimately create a new resource (for example the import action).


Thanks!

John


On 11/11/13, 8:05 PM, George Reese wrote:
I was asked at the OpenStack Summit to look at the Glance Tasks, 
particularly as a general pattern for other asynchronous operations.


If I understand Glance Tasks appropriately, different asynchronous 
operations get replaced by a single general purpose API call?


In general, a unified API for task tracking across all kinds of 
asynchronous operations is a good thing. However, assuming this 
understanding is correct, I have two comments:


#1 A consumer of an API should not need to know a priori whether a 
given operation is "asynchronous". The asynchronous nature of the 
operation should be determined through a response. Specifically, if 
the client gets a 202 response, then it should recognize that the 
action is asynchronous and expect a task in the response. If it gets 
something else, then the action is synchronous. This approach has the 
virtual of being proper HTTP and allowing the needs of the 
implementation to dictate the synchronous/asynchronous nature of the 
API call and not a fixed contract.


#2 I really don't like the idea of a single endpoint (/v2/tasks) for 
executing all tasks for a particular OpenStack component. Changes 
should be made through the resource being impacted.


-George

--
George Reese (george.re...@imaginary.com 
)
t: @GeorgeReese   m: +1(207)956-0217 
   Skype: nspollution






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


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

Re: [openstack-dev] [Glance] import task meeting 15:00 UTC Monday 26 August

[John Bresnahan]

On 08/23/2013 07:15 AM, Joshua Harlow wrote:
> I'm fine with either times. So maybe 1600 for all?

That time works for me.


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

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

[John Bresnahan]

Mark, good thoughts (as usual)

On 08/19/2013 09:15 PM, Mark Washenberger wrote:
> The goal isn't really to replace sqlalchemy completely.

Perhaps my problem is that I am not exactly sure what the goals are.
Cleanup (BL mixed in the BL seems wrong)?  HA or performance (are people
hitting limits that are traced to SQL) ?  Flexibility/Research
(plug-able modules for experimentation)?  I think it would help scope
the effort (and temper my concern about the work/reward ratio) if they
were enumerated in clear place.

> I'm hoping I can
> create a space where multiple drivers can operate efficiently without
> introducing bugs (i.e. pull all that business logic out of the driver!)
> I'll be very interested to see if people can, after such a refactoring,
> try out some more storage approaches, such as dropping the sqlalchemy
> orm in favor of its generic engine support or direct sql execution, as
> well as NoSQL what-have-you. We don't have to make all of the drivers
> live in the project, so it really can be a good place for interested
> parties to experiment.


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

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

[John Bresnahan]

> All I'm saying is that we should be careful not to swap one set of
> problems for another. 

My 2 cents: I am in agreement with Jay.  I am leery of NoSQL being a
direct sub in and I fear that this effort can be adding a large workload
for little benefit.

A somewhat related post:
http://www.joelonsoftware.com/articles/fog69.html

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

Re: [openstack-dev] [Glance] async worker design meeting tomorrow!

[John Bresnahan]

On 08/05/2013 04:34 AM, Brian Rosmaita wrote:
> Well, it's tomorrow as I write this, maybe it's today as you read
> this.  Anyway:
> 
> - asynchronous worker meeting Tuesday 6 Aug 2013 14:00 UTC in
> #openstack-glance
> 
> - the etherpad
> https://etherpad.openstack.org/havana-glance-requirements was updated
> after the last meeting
> 
> - if you missed the last meeting, the log is at
> https://etherpad.openstack.org/havana-glance-requirements-meeting-02-aug
>
> 
___
> OpenStack-dev mailing list OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

All,

I am very interested in this work but I cannot make the meeting because
it is at 4am my time and I am still sitting at my laptop as I stare down
the barrel of midnight.

I first want to thank Brain et al for the great work.  The wiki pages
they have are well thought out and defined.  I am very interested in
seeing that this work is successfully completed because I feel it is a
key part in making Glance a significantly more useful service.

When discussing this with the community in the past I have fallen into
the trap of getting lost in implementation details and thereby confused
the focus of the efforts first steps.  I am slightly concerned that this
meeting could take a turn into too much concern for details that are
better covered later (for example: how a task is implemented, what does
the plug in interface look like, will these tasks be scheduled via
messaging, etc).  Thus I thought I would send out what deliverables I
now hope will come from this meeting.  Here they are:

A near complete user facing REST API
 -- Brian has this well described in the previously linked wiki pages,
all that is needed is a y or n.  I vote y.

An agreed upon (initial/direction setting) set of use cases that this
API can handle.  As an example:

1) validate an incoming image as bootable
2) check an incoming image for a license
3) convert an image from one format to another (ex: raw->qcow2)
4) extract size information (image size vs storage size)
5) information injection/scrubbing from the image
6) perform an operator defined processor time intensive operation
   upon an image before allow it to be a) registered as a valid
   image location, b) downloaded.

A set of requirements for that REST API
-- ex:

   1) The lifespan of the client connection can be shorter than that of
  the workload.
   2) An image can be deleted without deleting the task associated with
  it (just an example!)
   3) multiple tasks can be performed on a single image safely at the
  same time
   4) A single task request is guaranteed to only happen once.  Two
  threads of execution will never iterate over the same byte,
  neither at the same time nor in serial (again, an example and one
  that admittedly may be beyond the scope of the API discussion).
-- on this point I am concerned with cases where a task fails
   and is restarted.  Do we guarantee that all tasks failed as
   well and thus can safely be restarted?

Thanks!

John

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

Re: [openstack-dev] Build-time unit tests failing when building glance 2013.2.b1

[John Bresnahan]

> 
> I believe we should fix the unittests to not shell out to glance-manage
> in that manner. One of the nice things about moving the code from bin/
> to glance.cmd is that it's available inside of the source tree for
> unittests! :) What we want to do is call the glance.cmd.manage:main()
> function directly. So, for instance, in:
> 
> glance/tests/functional/__init__.py
> and
> glance/tests/functional/test_glance_manage.py
> 
> We can call the function itself, rather than the shell wrapper.

That was the original intention and major motivation for the patch.
However the configuration information is globally shared in the process
space so pushing this through gave me pause.

> I'll make a patch. 

excellent!  thanks!

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